Следуете ли вы соглашению об именах оригинального программиста?

Да. Это облегчает следование людям, которые унаследуют его после вас. Я стараюсь немного подчищать код, чтобы сделать его более читабельным, если его действительно сложно понять.

Я согласен с тем, что оставить код в том виде, в котором его написал автор, можно до тех пор, пока этот код внутренне непротиворечив. Если коду трудно следовать из-за несогласованности, вы несете ответственность перед будущим сопровождающим ( наверное вы) чтобы было понятнее.

Если вы тратите 40 часов на выяснение того, что делает функция, потому что она использует плохо названные переменные и т. д., вам следует провести рефакторинг/переименовать для ясности/добавить комментарии/сделать все, что подходит для ситуации.

Тем не менее, если единственная проблема заключается в том, что наиболее последовательный стиль, который использовал автор, отличается от стандарта компании или того, к чему вы привыкли, я думаю, вы тратите свое время на переименование всего. Кроме того, вы можете потерять источник опыта, если первоначальный автор все еще доступен для вопросов, потому что он больше не узнает код.

Если вы не меняете весь существующий код на свой стандарт, я бы посоветовал придерживаться исходных соглашений, пока вы меняете эти файлы. Смешивание двух стилей кода в одном и том же файле уничтожает все преимущества, которые мог бы иметь согласованный стиль кода, и следующему парню придется постоянно спрашивать себя: «Кто написал эту функцию, как она будет называться — FooBar() или fooBar( )?"

Это становится еще сложнее, когда вы импортируете сторонние библиотеки — вы не хотите их переписывать, но стиль их кода может не совпадать с вашим. Так что, в конце концов, вы получите несколько разных соглашений об именах, и лучше всего провести четкую границу между «нашим кодом» и «их кодом».

Часто внесение массовых изменений в кодовую базу только для того, чтобы соответствовать руководству по стилю, — это просто способ ввести новые ошибки с небольшой добавленной стоимостью.

Это означает, что либо вы должны:

1. Обновляйте код, над которым вы работаете, чтобы он соответствовал руководству по мере работы над ним.

2. Используйте соглашения в коде, чтобы помочь будущим усилиям по обслуживанию.

Я бы порекомендовал 2., но венгерская нотация заставляет мои глаза кровоточить: с.

Если вы поддерживаете код, который написали другие и который другие люди будут поддерживать после вас, вы обязаны перед всеми участниками не вносить необоснованных изменений. Когда они зайдут в систему управления исходным кодом, чтобы увидеть, что вы изменили, они должны увидеть, что было необходимо для решения проблемы, над которой вы работали, а не миллион различий, потому что вы выполнили кучу глобальных поисков и заменили или переформатировали код, чтобы соответствует вашему любимому соглашению о сопоставлении фигурных скобок.

Конечно, если исходный код действительно отстой, все ставки сняты.

Как правило, да, в этом сценарии я бы предпочел условность и удобочитаемость стандартам. Никому не нравится этот ответ, но это правильно, чтобы поддерживать код в долгосрочной перспективе.

Когда хороший программист читает код, он должен уметь анализировать имена переменных и отслеживать некоторые из них в своей голове — до тех пор, пока они непротиворечивы, по крайней мере, в исходном файле. Но если вы нарушите эту последовательность, это, скорее всего, заставит программиста, читающего код, страдать от некоторого когнитивного диссонанса, что затем затруднит отслеживание. Это не убийца — хорошие программисты справятся с этим, но они проклянут ваше имя и, возможно, разместят вас на TheDailyWTF.

Я, безусловно, буду продолжать использовать то же соглашение об именах, так как оно будет поддерживать согласованность кода (даже если он постоянно уродлив) и более читабельно, чем смешивание соглашений об именах переменных. Человеческий мозг, кажется, довольно хорошо справляется с распознаванием образов, и на самом деле вы не хотите подвергать мозг опасности, безосновательно нарушая указанный образец.

Тем не менее, я далеко не знаток венгерской нотации, но если это то, с чем вам приходится работать...

Если файл или проект уже написан с использованием согласованного стиля, вам следует попытаться следовать этому стилю, даже если он конфликтует/противоречит вашему существующему стилю. Одной из основных целей стиля кода является согласованность, поэтому, если вы введете другой стиль в код, который уже согласован (внутри себя), вы потеряете эту согласованность.

Если код написан плохо и требует некоторого уровня очистки, чтобы понять его, то очистка стиля становится более подходящим вариантом, но вы должны делать это только в случае крайней необходимости (особенно если нет модульных тестов) при запуске. возможность внесения неожиданных критических изменений.

Абсолютно да. Единственный случай, когда я не считаю предпочтительным следовать соглашению об именах исходного программиста, - это когда исходный программист (или последующие разработчики, которые с тех пор модифицировали код) не соблюдали какое-либо согласованное соглашение об именах.

Да. Я на самом деле написал это в стандартном документе. Я создал в моей текущей компании:

Существующий код заменяет все другие стандарты и методы (будь то общеотраслевые стандарты или стандарты, описанные в этом документе). В большинстве случаев вам следует настроить свой код так, чтобы он соответствовал существующему коду в тех же файлах, по двум причинам:

1. Чтобы избежать использования нескольких различных стилей/шаблонов в одном модуле/файле (что противоречит цели стандартов и затрудняет сопровождение).
2. Усилия по рефакторингу существующего кода могут быть неоправданно более дорогостоящими (отнимающими много времени и способствующими появлению новых ошибок).

Лично всякий раз, когда я берусь за проект с другой схемой именования переменных, я склонен сохранять ту же схему, которую использовал предыдущий программист. Единственное, что я делаю по-другому, это для любых новых переменных, которые я добавляю, я ставлю подчеркивание перед именем переменной. Таким образом, я могу быстро увидеть свои переменные и свой код, не заходя в исходную историю и не сравнивая версии. Но когда дело доходит до наследования просто нечитаемого кода или комментариев, я обычно просматриваю их и подчищаю как могу, не переписывая все это целиком (дошло до этого). Организация — это ключ к расширяемому коду!

если я могу прочитать код, я (пытаюсь) принять те же соглашения, если он все равно не читается, мне нужно провести рефакторинг и, таким образом, значительно изменить его (в зависимости от того, что ему нравится)

Зависит от. Если я создаю новое приложение и краду код из устаревшего приложения с дерьмовыми именами переменных, я проведу рефакторинг, как только получу его в свое приложение.

Да… Мало что может разочаровать больше, чем войти в приложение, которое имеет два совершенно разных стиля. В одном проекте, над которым я недавно работал, было два разных способа манипулирования файлами, два разных способа реализации экранов, две разные фундаментальные структуры. Второй кодер даже зашел так далеко, что сделал новые функции частью dll, которая вызывается из основного кода. Обслуживание было кошмарным, и мне приходилось изучать обе парадигмы и надеяться, что когда я был в одном разделе, я работал с правильным.

Когда в Риме поступай как римляне.

(За исключением имен индексных переменных, например «iArrayIndex++». Хватит потворствовать этому идиотизму.)

Я думаю об исправлении ошибок как о хирургической процедуре. Входите, беспокойте как можно меньше, исправляйте это, уходите, оставляйте как можно меньше следов своего пребывания там.

Да, но, к сожалению, до меня несколько разработчиков не соблюдали это правило, поэтому у меня есть несколько соглашений об именах на выбор.

Но иногда у нас есть время все исправить, чтобы в итоге все было красиво и чисто.

Если в коде уже есть согласованный стиль, в том числе в именовании, я стараюсь следовать ему. Если предыдущие программисты не были последовательны, то я могу свободно применять стандарт компании или мои личные стандарты, если стандарта компании нет.

В любом случае я стараюсь отметить сделанные мной изменения, обрамляя их комментариями. Я знаю, что в современных системах CVS это часто не делается, но я все же предпочитаю это делать.

К сожалению, в большинстве случаев ответ положительный. В большинстве случаев код не следует хорошим соглашениям, поэтому трудно следовать прецеденту. Но для удобочитаемости иногда необходимо плыть по течению.

Однако, если это достаточно маленькое приложение, и я могу реорганизовать большую часть существующего кода, чтобы он лучше «пахнул», я сделаю это. Или, если это часть более крупной переделки, я также начну кодирование с использованием текущих стандартов кодирования. Но обычно это не так.

Если в существующем приложении есть стандарт, я думаю, лучше следовать ему. Если нет стандарта (перемешиваются табуляции и пробелы, фигурные скобки везде... о ужас), то я делаю то, что считаю лучшим, и обычно запускаю существующий код через инструмент форматирования (например, Vim). Я всегда буду сохранять стиль заглавных букв и т. д. существующего кода, если есть последовательный стиль.

Мое единственное исключение из этого правила состоит в том, что я не буду использовать венгерскую нотацию, если кто-то не приставит пистолет к моей голове. Я не буду тратить время на переименование существующих вещей, но все, что я добавлю новое, не будет иметь никаких венгерских бородавок.