Я называю свои переменные, используя соглашения .Net:
- camelCase для переменных и полей (я склонен использовать _camelCase для приватных полей в классе)
- PascalCase для методов, свойств и классов
Единственное место, где я отклоняюсь, это константы и перечисления, где я на самом деле предпочитаю стиль Java SCREAMING_CAPS.
Кодовая база моей компании усеяна псевдо-венгерским стилем обозначений из VB6 и VBScript, если не полноценным венгерским, т.е.
- s или str для строк
- я или int для Ints
- д для десятичной (или иногда двойной)
- o или obj для любого типа объекта
Я съеживаюсь всякий раз, когда вижу, что стиль кода используется в чужом коде (даже в коде с нуля, а не только в устаревшем коде), и я отказываюсь использовать этот стиль самостоятельно В прошлом я поднял вопрос стандартизации соглашений об именах .Net, и это просто игнорируется - люди, которые пишут на венгерском языке, продолжают это делать, те из нас, кто не любит меня, продолжают использовать наш собственный стиль; Я немного боюсь, что если мы действительно стандартизируем (что я продолжаю настаивать, но, похоже, никого больше это не волнует), это будет на венгерской нотации, а не на рекомендованном пути, и тогда я буду вынужден писать такой код ,
Я делаю из мухи слона в отношении этого? Разве мне все равно, если код полон избыточных идентификаторов, а не описательных имен, и продолжать использовать свой собственный путь и настаивать на том, чтобы это стало стандартом?
источник
Ответы:
Единственное, о чем вы должны заботиться, это то, что вы работаете в команде, где люди не заботятся о том, чтобы что-то почистить. Это очень грустно.
Делайте то, что вы делаете, продолжайте использовать современный стиль и приглашайте людей (но не заставляйте их) также принять его. Это займет время, конечно. Через некоторое время вы увидите, идет ли он куда-нибудь и что вы будете делать дальше.
PS Как насчет организации встречи по этому вопросу и приглашения всех участников. Тогда вы получите их полное внимание, обозначите проблему и представите свой подход. Это даст им возможность подумать. Возможно из ваших локальных попыток они не воспринимают вас очень серьезно.
источник
SendNewCustomerEmailкоторый используется для отправки всех видов электронных писем, а не только новых электронных писем клиентов. В нем есть комментарий от текущего разработчика, который гласит: «Обратите внимание, что это имя вводит в заблуждение», но никто даже не задумывался над тем, чтобы переименовать его в нечто более общее и полезное, и если я сделаю это, менеджер попросит меня объяснить, почему я Я изменяю код, который не нужно менять, вместо того, чтобы добавлять ценность.Я думаю, что вы, возможно, должны спросить себя, влияет ли венгерская нотация на ваш личный результат / качество, или это больше просто вредит вашему эго. Под эго я имею в виду, что в целом все работает нормально, но вы бы никогда не хотели, чтобы кто-то, кого вы уважаете извне, видел позорно устаревший код. Хотя я думаю, что у этой проблемы есть свои достоинства, вы должны взвесить ее в сравнении с ударом по качеству / производительности, с которым столкнется каждый, кто должен был переключиться.
Это своего рода вопрос технического долга, поскольку вы совершенно правы, что этот стиль венгерского не имеет смысла в .Net (за исключением интерфейсов с «I», но это в другой раз), однако это может быть своего рода техническая задолженность, с которой ваша команда может жить, пока она, естественно, не исчезнет .
источник
CustomerRepositoryи с классомCustomerRepositoryImplили подобным.Xmlвместо XML используется префикс XMLExtensibleMarkupLanguage. В модуле бухгалтерского учета я ожидал бы увидеть объекты счета-фактуры, такие какarInvoiceиapInvoiceкоторые передают бизнес-контекст, но видятobjArInvoiceилиoApInvoiceпросто глупо ИМО. Я предполагаю, что это могло быть хуже, это могло бытьclsApInvoiceдля фактического имени классаЛучший аргумент против венгерской нотации, кроме современных IDE, которые имеют множество методов, чтобы показать тип, видимость и многое другое переменной с цветом, с крошечными символами и с подсказками во время пылесоса, состоит в том, чтобы относиться к этому серьезно.
Серьезно: при рефакторинге вы можете изменить переменную с int на long, со String на char. Вам не нужно менять имя тоже.
В IDE имена часто сортируются в боксе сбоку. отсортировано по названию, где его легко найти. Если большинство переменных начинаются с o или i, это мешает глазам добраться до значительной части имени.
Дополнительные символы нарушают семантику переменной. Целое число «нормальный» получает «i_sane», который больше похож на «безумный».
Венгерская нотация была полезна в языках, в которых отсутствует система типов. Вам это не нужно, если компилятор применяет определенные типы. Если вы украсите свой ламенто о венгерской нотации эмпатическим «да, для старших программистов, в прошлом имело смысл использовать его!», Эти старшие программисты могли бы быть напрасными и предпочитать, чтобы их не называли старыми.
Но вы должны быть осторожны, чтобы техника работала. Может быть, вы можете понизить голос, говоря о «старших программистах», чтобы они почувствовали, насколько вы осторожны с ними, насколько им нужен уход. Чтобы третий человек в комнате узнал, что вы пытаетесь что-то скрыть, что, конечно, вызовет у него любопытство.
источник
eSomeEnumкак используется в некоторых местах; к счастью, не часто.Купите копию Руководства по разработке дизайна и поместите ее на рабочий стол вашего менеджера (или любого, кто контролирует стиль кодирования). Обязательно поместите в заметку заметку, явно указывающую на введение, где они подчеркивают важность последовательности. Чтобы продолжить путь к цели, возьмите копию Чистого кода и поставьте там закладку в разделе, касающемся соглашений о кодировании.
источник
В некотором отношении это субъективная проблема, и это одна из тех дискуссий по программированию (орфография?), Которую я развлекаю некоторое время, а затем избегаю. Хотя я думаю, что венгерская нотация - это грех, который должен быть изгнан, я думаю, что последовательность важнее.
В этом ключе я сделаю все возможное, чтобы убедить команду использовать именование переменных, ориентированное на домен, а не соглашения о присвоении имен, основанные на типах, но если все сложится, я отступлю, чтобы принять стандарт именования, которому все должны соответствовать общая кодовая база.
Я не сторонник какого-то общепринятого стандарта, навязанного группой стандартов, но команды разработчиков разрабатывают свой собственный стандарт и, что более важно, придерживаются его.
источник
Благодаря резкому переименованию переменных происходит так быстро, что я могу так быстро отменить плохо продуманные соглашения о присвоении имен, что мне не нужно оставлять старые, ошибочные соглашения.
Если у вас нет инструментов рефакторинга, тогда я согласен с другими комментаторами, которые предложили, насколько это возможно, следовать существующему соглашению кодовой базы, даже если оно было ошибочным. (до определенного момента существуют соглашения об именовании переменных, которые превратятся в генераторы ошибок, если вы позволите им)
источник
Большинство ваших опасений справедливы и могут облегчить жизнь новому разработчику и, возможно, вашему здравомыслию. Единственное соглашение, которое вы должны принять, - это описательные имена. Вы должны быть в состоянии прийти к какому-то единодушному согласию по этому вопросу без резкого изменения стилей в зависимости от того, насколько они плохие. Во всем остальном, либо подождите, пока вы не будете отвечать, либо замените текущих участников новыми разработчиками, которые думают и чувствуют то, что вы делаете.
источник
Мои отклонения:
Области общего кода и расположение файлов:
источник