Стоит ли заботиться о правилах именования?

Я называю свои переменные, используя соглашения .Net:

• camelCase для переменных и полей (я склонен использовать _camelCase для приватных полей в классе)
• PascalCase для методов, свойств и классов

Единственное место, где я отклоняюсь, это константы и перечисления, где я на самом деле предпочитаю стиль Java SCREAMING_CAPS.

Кодовая база моей компании усеяна псевдо-венгерским стилем обозначений из VB6 и VBScript, если не полноценным венгерским, т.е.

• s или str для строк
• я или int для Ints
• д для десятичной (или иногда двойной)
• o или obj для любого типа объекта

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

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

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

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

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

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

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

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

• Поощряйте больше недоброжелательности (b) ool (f) loat (c) har (l) ong (s) hort (конфликтует со строкой? No: (S) tring), (v) oid.
• Поощряйте кодирование видимости. Я из Javaland, и надеюсь, что он подходит и для .net: (pri) vate, (pub) blic, (pro) tected (def) ault следует использовать.
• .net имеет final / const? Сделайте это префиксом! Слышу ли я «изменчивый»?
• Зачем int и long нужен префикс, а разные объекты - нет? Это не логично. Создайте abbrev.tab. где каждый новый объект получает отдельное сокращение.
• Переменные, которые могут быть нулевыми, и такие, которые никогда не должны быть нулевыми, также могут иметь префикс. Умные люди помещают весь DbC в префикс переменной.

Серьезно: при рефакторинге вы можете изменить переменную с int на long, со String на char. Вам не нужно менять имя тоже.

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

Дополнительные символы нарушают семантику переменной. Целое число «нормальный» получает «i_sane», который больше похож на «безумный».

Венгерская нотация была полезна в языках, в которых отсутствует система типов. Вам это не нужно, если компилятор применяет определенные типы. Если вы украсите свой ламенто о венгерской нотации эмпатическим «да, для старших программистов, в прошлом имело смысл использовать его!», Эти старшие программисты могли бы быть напрасными и предпочитать, чтобы их не называли старыми.

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

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

В некотором отношении это субъективная проблема, и это одна из тех дискуссий по программированию (орфография?), Которую я развлекаю некоторое время, а затем избегаю. Хотя я думаю, что венгерская нотация - это грех, который должен быть изгнан, я думаю, что последовательность важнее.

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

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

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

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

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

Мои отклонения:

• _PublicPropertyBacker
• _private_property_backer
• _privateMember
• CONSTANT_MEMBER
• privateFunction
• param_
• приватная кнопка окбу; //и т.д. ограничить 3 символа
• struct SOMESTRUCT // для структуры pinvoke

Области общего кода и расположение файлов:

• члены
  • (приватный | внутренний | защищенный | публичный) X [статический] X [постоянный / только для чтения]
• свойства
  • (приватный | внутренний | защищенный | публичный) X [статический] X [только для чтения]
• Конструкторы
  • (приватный | внутренний | защищенный | публичный) X [статический]
• Команды // что-нибудь с пустым возвратом или возвращением статуса
  • (открытый | защищенный | внутренний | закрытый) X [статический]
• Обработчики событий / частные /
  • (Управление | Удаленный | Сервис | Другое) События
• Функции // запрашивают состояние, не должны иметь побочных эффектов
  • (открытый | защищенный | внутренний | закрытый) X [статический]