Соблюдаете ли вы соглашение об именах оригинального программиста?
Если вы берете проект у кого-то для выполнения простых обновлений, соблюдаете ли вы соглашение об именах? Я только что получил проект, где предыдущий программист везде использовал венгерскую нотацию. Наш основной продукт имеет стандарт именования, но у нас было много людей, которые на протяжении многих лет создавали собственные отчеты и делали все, что им хотелось.
У меня нет времени, чтобы изменить все имена переменных уже в коде, хотя.
Я склонен к читабельности, чтобы просто продолжить соглашение об именах.
20 ответов
Да. Это облегчает следовать людям, которые наследуют это после вас. Я стараюсь немного почистить код, чтобы сделать его более читабельным, если его действительно трудно понять.
Если вы не изменяете весь существующий код в соответствии со своим стандартом, то я бы сказал, придерживайтесь исходных соглашений, пока вы меняете эти файлы. Смешивание двух стилей кода в одном и том же файле разрушает любую выгоду, которую имел бы согласованный стиль кода, и следующий парень должен был бы постоянно спрашивать себя "кто написал эту функцию, как она будет называться - FooBar() или fooBar()?"
Подобные вещи становятся еще сложнее, когда вы импортируете сторонние библиотеки - вы не хотите их переписывать, но их стиль кода может не соответствовать вашему. Таким образом, в итоге вы получите несколько различных соглашений об именах, и лучше всего провести четкие линии между "нашим кодом" и "их кодом".
Я согласен предположить, что оставить код в том виде, в котором он был написан автором, хорошо, если этот код внутренне согласован. Если код трудно следовать из-за несоответствия, вы несете ответственность перед будущим сопровождающим (возможно, за вас), чтобы сделать его более понятным.
Если вы потратите 40 часов на то, чтобы понять, что делает функция, потому что она использует переменные со слабым именем и т. Д., Вам следует провести рефакторинг / переименовать для ясности / добавить комментарий / сделать все, что подходит для ситуации.
Тем не менее, если единственная проблема заключается в том, что наиболее последовательный стиль, который использовал автор, отличается от стандарта компании или того, к чему вы привыкли, я думаю, вы тратите время на переименование всего. Кроме того, вы можете потерять опыт, если первоначальный автор все еще доступен для вопросов, потому что он больше не распознает код.
Часто внесение оптовых изменений в кодовую базу просто для соответствия руководству по стилю - это просто способ представить новые ошибки с небольшой добавленной стоимостью.
Это означает, что либо вы должны:
Обновите код, над которым вы работаете, чтобы он соответствовал руководящим принципам, когда вы работаете над ним.
Используйте соглашения в коде, чтобы помочь будущим усилиям по обслуживанию.
Я бы порекомендовал 2., но венгерская нотация заставляет мои глаза кровоточить: с.
Если вы поддерживаете код, который написали другие, и который другие люди будут поддерживать после вас, вы обязаны сделать это всем, чтобы не вносить безвозмездные изменения. Когда они входят в систему контроля исходного кода, чтобы увидеть, что вы изменили, они должны увидеть, что необходимо для решения проблемы, над которой вы работали, а не миллион различий, потому что вы выполнили кучу глобальных поисков и заменили или переформатировали код в соответствовать вашему любимому соглашению соответствия скобок.
Конечно, если исходный код действительно отстой, все ставки сняты.
Абсолютно да. Единственный случай, когда я не верю, что предпочтительнее следовать первоначальному соглашению об именах программиста, - это когда первоначальный программист (или последующие разработчики, которые изменили код с тех пор) не соблюдает какое-либо согласованное соглашение об именах.
Да. Я написал это в стандарте. Я создал в моей нынешней компании:
Существующий код заменяет все другие стандарты и практики (будь то отраслевые стандарты или стандарты, описанные в этом документе). В большинстве случаев вы должны хамелеонить свой код, чтобы он соответствовал существующему коду в тех же файлах, по двум причинам:
- Во избежание наличия нескольких отдельных стилей / шаблонов в одном модуле / файле (которые противоречат целям стандартов и препятствуют удобству обслуживания).
- Усилия по рефакторингу существующего кода склонны быть излишне более дорогостоящими (трудоемкими и способствующими появлению новых ошибок).
В общем, да, я бы пошел на условность и удобочитаемость по стандартам в этом сценарии. Никому не нравится этот ответ, но это правильная вещь, чтобы сделать код поддерживаемым в течение длительного времени.
Когда хороший программист читает код, он должен уметь анализировать имена переменных и отслеживать их в своей голове - до тех пор, пока они согласованы, по крайней мере, в исходном файле. Но если вы нарушите эту согласованность, это, вероятно, заставит программиста, читающего код, испытать некоторый когнитивный диссонанс, который затем усложнит отслеживание. Это не убийца - хорошие программисты справятся с этим, но они проклянут ваше имя и, вероятно, разместят вас на TheDailyWTF.
Если файл или проект уже написаны с использованием согласованного стиля, вы должны попытаться следовать этому стилю, даже если он противоречит / противоречит вашему существующему стилю. Одной из основных целей стиля кода является согласованность, поэтому, если вы вводите другой стиль в коде, который уже согласован (внутри себя), вы теряете эту согласованность.
Если код плохо написан и требует некоторого уровня очистки, чтобы понять его, то очистка стиля становится более подходящей опцией, но вы должны делать это только в случае крайней необходимости (особенно если нет модульных тестов), когда вы запускаете возможность внесения неожиданных переломных изменений.
Я, конечно, продолжал бы использовать то же соглашение об именах, так как оно будет сохранять код непротиворечивым (даже если он постоянно уродливым) и более читабельным, чем смешивание соглашений об именах переменных. Человеческий мозг, кажется, довольно хорош в распознавании паттернов, и вы не хотите бросать мозги в кривая, безвозмездно нарушая этот паттерн.
Тем не менее, я не что иное, как несколько венгерских обозначений, но если это то, что вы должны работать с...
Когда в Риме делай, как римляне.
(За исключением имен переменных индекса, например, "iArrayIndex++". Прекратите оправдывать этот идиотизм.)
Лично всякий раз, когда я беру проект, имеющий другую схему именования переменных, я склоняюсь к той же схеме, которая использовалась предыдущим программистом. Единственное, что я делаю по-разному, - это для любых новых переменных, которые я добавляю, я ставлю подчеркивание перед именем переменной. Таким образом, я могу быстро увидеть мои переменные и мой код, не заходя в историю исходников и не сравнивая версии. Но когда дело доходит до того, что я наследую просто нечитаемый код или комментарии, я обычно просматриваю их и очищаю, как могу, без переписывания всего этого (до этого дошло). Организация - это ключ к тому, чтобы иметь расширяемый код!
Да. Есть немного более неприятно, чем идти в приложение, которое имеет два совершенно разных стиля. В одном проекте, над которым я работал, было два разных способа манипулирования файлами, два разных способа реализации экранов, две разные фундаментальные структуры. Второй кодер даже зашел так далеко, что сделал новые функции частью библиотеки DLL, которая вызывается из основного кода. Техническое обслуживание было кошмарным, и я должен был изучить обе парадигмы и надежду, когда я был в одной секции, я работал с правильной.
Зависит. Если я создаю новое приложение и краду код из унаследованного приложения с именами переменных дерьма, я проведу рефакторинг, как только получу его в свое приложение.
К сожалению, в большинстве случаев ответ - да. В большинстве случаев код не следует хорошим соглашениям, поэтому трудно следовать прецеденту. Но для удобства чтения иногда необходимо идти по течению.
Тем не менее, если это достаточно маленькое приложение, которое я могу реорганизовать для существующего кода, чтобы лучше "пахнуть", я сделаю это. Или, если это часть большей переписки, я также начну кодирование с текущими стандартами кодирования. Но обычно это не так.
Если я могу прочитать код, я (пытаюсь) принять те же соглашения, если он все равно не читается, мне нужно провести рефакторинг и, таким образом, изменить его (в зависимости от того, на что это похоже)
Если код уже имеет непротиворечивый стиль, включая именование, я стараюсь следовать ему. Если предыдущие программисты были непоследовательны, тогда я мог бы свободно применять корпоративный стандарт или мои личные стандарты, если не существует какого-либо корпоративного стандарта.
В любом случае я пытаюсь отметить сделанные мной изменения, обрамляя их комментариями. Я знаю, что с сегодняшними системами CVS это часто не делается, но я все же предпочитаю это делать.
Да, но, к сожалению, там, где до меня работали несколько разработчиков, которые не соответствовали этому правилу, поэтому у меня есть несколько соглашений об именах.
Но иногда у нас есть время, чтобы все исправить, так что в итоге все будет красиво и чисто.
Я думаю сделать исправление ошибки как хирургическую процедуру. Входи, как можно меньше мешай, чини это, уходи, оставь как можно меньше следов своего бытия.
Если в существующем приложении есть стандарт, я думаю, что лучше всего следовать ему. Если не существует стандарта (табуляция и пробелы смешиваются, фигурные скобки везде... о ужас), тогда я делаю то, что считаю лучшим, и обычно запускаю существующий код с помощью инструмента форматирования (например, Vim). Я всегда буду сохранять стиль заглавных букв и т. Д. Существующего кода, если есть согласованный стиль.
Единственным исключением из этого правила является то, что я не буду использовать венгерскую нотацию, если у кого-то нет пистолета в голову. Я не буду тратить время на переименование существующего материала, но все, что я добавлю новое, не будет иметь никаких венгерских бородавок.