Следуете ли вы соглашению об именовании оригинального программиста?
https://stackoverflow.com/questions/284113
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Если вы берете на себя управление проектом у кого-то для выполнения простых обновлений, соблюдаете ли вы их соглашение об именовании?Я только что получил проект, в котором предыдущий программист везде использовал венгерскую нотацию.У нашего основного продукта есть стандарт именования, но за эти годы у нас было много людей, которые создавали пользовательские отчеты и делали все, что им заблагорассудится.
Однако у меня нет времени изменять все имена переменных, которые уже есть в коде.
Я склоняюсь к удобочитаемости, просто продолжая придерживаться их соглашения об именовании.
Решение
Да, я делаю. Это облегчает следовать людям, которые наследуют это после вас. Я стараюсь немного почистить код, чтобы сделать его более читабельным, если его действительно трудно понять.
Другие советы
Я согласен с тем, что оставить код в том виде, в котором он был написан автором, - это хорошо, если этот код внутренне непротиворечив. Если за кодом трудно следовать из-за непоследовательности, вы несете ответственность за будущий сопровождающий (вероятно, вы), чтобы прояснить ситуацию.
Если вы потратите 40 часов на то, чтобы выяснить, что делает функция, потому что она использует переменные со слабым именем и т. д., вы должны рефакторинг / переименовать для ясности / добавить комментарий / сделать все, что подходит для ситуации.
Тем не менее, если единственная проблема заключается в том, что наиболее последовательный стиль, который использовал автор, отличается от стандарта компании или того, к чему вы привыкли, я думаю, вы тратите время на переименование всего. Кроме того, вы можете потерять опыт, если первоначальный автор все еще доступен для вопросов, потому что он больше не будет распознавать код.
Если вы не изменяете весь существующий код в соответствии со своим стандартом, то я бы сказал, что придерживайтесь первоначальных соглашений, пока вы меняете эти файлы. Смешивание двух стилей кода в одном и том же файле разрушает любую выгоду, которую имел бы согласованный стиль кода, и следующий парень должен был бы постоянно спрашивать себя «кто написал эту функцию, как она будет называться - FooBar () или fooBar» () & Quot;?
Подобные вещи становятся еще сложнее, когда вы импортируете сторонние библиотеки - вы не хотите их переписывать, но их стиль кода может не соответствовать вашему. Таким образом, в итоге вы получите несколько различных соглашений об именах, и лучше всего провести четкие линии между " нашим кодом " и "их код".
Часто внесение оптовых изменений в кодовую базу просто для соответствия руководству по стилю - это просто способ представить новые ошибки с небольшой добавленной стоимостью.
Это означает, что вы должны:
<Ол>Обновите код, над которым вы работаете, чтобы он соответствовал руководящим принципам, когда вы работаете над ним.
Используйте условные обозначения в коде, чтобы помочь будущим усилиям по обслуживанию.
Я бы порекомендовал 2., но венгерская нотация заставляет мои глаза кровоточить: с.
Если вы поддерживаете код, который написали другие, и который другие люди будут поддерживать после вас, вы обязаны сделать это всем, чтобы не вносить необоснованные изменения. Когда они заходят в систему контроля исходного кода, чтобы увидеть, что вы изменили, они должны увидеть, что необходимо для решения проблемы, над которой вы работали, а не миллион различий, потому что вы выполнили кучу глобальных поисков и заменили или переформатировали код, чтобы соответствовать вашему любимому соглашению о соответствии скобок.
Конечно, если исходный код действительно плохой, все ставки отменены.
В общем, да, я бы пошел на соглашение и удобочитаемость по стандартам в этом сценарии. Никому не нравится этот ответ, но это правильная вещь, чтобы сделать код поддерживаемым в течение длительного времени.
Когда хороший программист читает код, он должен уметь анализировать имена переменных и отслеживать несколько из них в своей голове - до тех пор, пока они согласованы, по крайней мере, в исходном файле. Но если вы нарушите эту последовательность, это, вероятно, заставит программиста, читающего код, испытать некоторый когнитивный диссонанс, который затем усложнит отслеживание. Это не убийца - хорошие программисты справятся с этим, но проклянут ваше имя и, вероятно, отправят вам сообщение на TheDailyWTF .
Я, конечно, продолжал бы использовать то же соглашение об именах, так как оно сохранит код непротиворечивым (даже если он ужасно уродливым) и будет более читабельным, чем смешивание соглашений об именах переменных. Человеческий мозг, кажется, довольно хорош в распознавании образов, и вы не хотите бросать мозг в кривую, безвозмездно нарушая указанный рисунок.
Тем не менее, я не что иное, как несколько венгерских обозначений, но если это то, с чем вам нужно работать ...
Если файл или проект уже написаны с использованием согласованного стиля, вы должны попытаться следовать этому стилю, даже если он противоречит / противоречит существующему стилю. Одна из основных целей стиля кода - это согласованность, поэтому, если вы введете другой стиль в коде, который уже согласован (внутри себя), вы потеряете эту согласованность.
Если код плохо написан и требует некоторого уровня очистки, чтобы понять его, то очистка стиля становится более подходящей опцией, но вы должны делать это только в случае крайней необходимости (особенно если нет юнит-тестов), как Вы запускаете возможность внесения неожиданных критических изменений.
Абсолютно да. Единственный случай, когда я не верю, что предпочтительнее следовать соглашению об именах исходного программиста, это когда первоначальный программист (или последующие разработчики, которые изменили код с тех пор) не соблюдает какое-либо согласованное соглашение об именах.
ДА.На самом деле я написал это в документе по стандартам.Я творил в своей нынешней компании:
Существующий кодекс заменяет все другие стандарты и практики (будь то общеотраслевые стандарты или те, которые приведены в этом документе).В большинстве случаев вам следует изменить свой код, чтобы он соответствовал существующему коду в тех же файлах, по двум причинам:
- Чтобы избежать наличия нескольких различных стилей / шаблонов в одном модуле / файле (которые противоречат назначению стандартов и препятствуют сопровождаемости).
- Усилия по рефакторингу существующего кода могут оказаться неоправданно более дорогостоящими (отнимающими много времени и приводящими к появлению новых ошибок).
Лично, когда я беру проект, имеющий другую схему именования переменных, я склоняюсь к той же схеме, которая использовалась предыдущим программистом. Единственное, что я делаю по-разному, это для любых новых переменных, которые я добавляю, я ставлю подчеркивание перед именем переменной. Таким образом, я могу быстро увидеть мои переменные и мой код, не заходя в историю исходников и не сравнивая версии. Но когда дело доходит до того, что я наследую просто нечитаемый код или комментарии, я обычно просматриваю их и очищаю, как могу, без переписывания всего этого (до этого дошло). Организация - это ключ к наличию расширяемого кода!
если я могу прочитать код, я (попробую) принять те же соглашения если он все равно не читается, мне нужно провести рефакторинг и, следовательно, изменить его (в зависимости от того, на что это похоже), значительно
Зависит от обстоятельств.Если я создаю новое приложение и краду код из устаревшего приложения с дерьмовым наименованием переменных, я проведу рефакторинг, как только получу его в свое приложение.
ДА..Нет ничего более неприятного, чем зайти в приложение, которое имеет два совершенно разных стиля.В одном проекте, над которым я недавно работал, было два разных способа манипулирования файлами, два разных способа реализации экранов, две разные фундаментальные структуры.Второй программист даже зашел так далеко, что сделал новые функции частью библиотеки dll, которая вызывается из основного кода.Обслуживание было кошмарным, и мне пришлось изучить обе парадигмы и надеяться, что когда я был в одном разделе, я работал с правильной.
Когда в Риме делают так, как делают римляне.
(За исключением имен переменных индекса, например, «iArrayIndex ++». Прекратите оправдывать этот идиотизм.)
Я думаю сделать исправление ошибки как хирургическую процедуру. Садись, мешай как можно меньше, чини это, убирайся, оставь как можно меньше следов своего бытия.
Да, но, к сожалению, там, где до меня работали несколько разработчиков, которые не соответствовали этому правилу, поэтому у меня есть несколько соглашений об именах.
Но иногда у нас есть время, чтобы все исправить, так что в итоге все будет хорошо и чисто.
Если код уже имеет непротиворечивый стиль, включая именование, я стараюсь следовать ему. Если предыдущие программисты были непоследовательны, тогда я мог бы свободно применять корпоративный стандарт или мои личные стандарты, если нет какого-либо корпоративного стандарта.
В любом случае я пытаюсь отметить сделанные мной изменения, обрамляя их комментариями. Я знаю, что с сегодняшними системами CVS это часто не делается, но я все же предпочитаю это делать.
К сожалению, в большинстве случаев ответ положительный. В большинстве случаев код не следует хорошим соглашениям, поэтому трудно следовать прецеденту. Но для удобства чтения иногда необходимо идти по течению.
Однако , если это достаточно маленькое приложение, я могу реорганизовать большую часть существующего кода, чтобы "нюхать" лучше тогда сделаю. Или, если это часть большей переписки, я также начну кодирование с текущими стандартами кодирования. Но обычно это не так.
Если в существующем приложении есть стандарт, я думаю, что лучше всего ему следовать. Если не существует стандарта (табуляция и пробелы смешаны, фигурные скобки везде ... о ужас), тогда я делаю то, что считаю лучшим, и обычно запускаю существующий код с помощью инструмента форматирования (например, Vim). Я всегда буду сохранять стиль заглавных букв и т. Д. Существующего кода, если есть согласованный стиль.
Единственным исключением из этого правила является то, что я не буду использовать венгерскую нотацию, если у кого-то нет пистолета в голову. Я не буду тратить время на переименование существующего материала, но все, что я добавлю новое, не будет иметь никаких венгерских бородавок.
