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

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

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

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

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

такие вещи становятся еще сложнее, когда вы импортируете 3rd party библиотеки - вы не хотите переписывать их, но их стиль кода может не соответствовать вашему. Таким образом, в конце концов вы получите несколько различных соглашений об именах, и лучше всего провести четкие линии между "нашим кодом" и "их кодом".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

когда в Риме делай, как римляне.

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

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

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

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

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

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

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

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

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

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