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

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

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

Это означает, что вам либо следует:

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

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

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

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

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

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

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

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

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

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

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

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

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

Подобные вещи становятся еще сложнее, когда вы импортируете сторонние библиотеки - вы не хотите их переписывать, но их стиль кода может не совпадать с вашим. В итоге вы получите несколько различных соглашений об именах, и лучше всего провести четкие линии между «нашим кодом» и «их кодом».

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

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

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

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

Находясь в Риме, делайте то же, что и римляне.

(За исключением имен индексных переменных, например, "iArrayIndex ++". Перестаньте мириться с этим идиотизмом.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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