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

Question

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

У меня нет времени, чтобы изменить все имена переменных, которые уже есть в коде.

Я склонен к читабельности, чтобы просто продолжить соглашение об именах.

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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