Casper-SC
@Casper-SC
Программист (.NET)

Стиль оформления кода в .NET приложениях. Встречался ли вам ад в коде?

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

Поясняю. Если есть нормальная IDE, то венгерская нотация нафиг не нужна, код превращается в рябь из смеси сокращений, которые только раздражают. Навёл мышь, увидел тип данных, а так по сути всё и так понятно, когда на код смотришь. Нажал на переменную, подсветилась везде в коде она. Всё просто и ясно.

Я видел код, в котором переменные выглядит так:
public void Method(string[] arlines)
{
    int nIndex = 0; //далее эта переменная используется на 3 строках ниже
    //и всё! Нафига писать, что она типа int в названии? 
    //Ну видно же, что это за переменная парой строк выше.
}

А-а-а, он серьёзно? Нафига писать, что это Array (ar)? Почему после ar следующее слово с маленькой буквы? Код для кого пишется для людей или просто, чтобы он был как можно менее читабельным?

public static bool Serialize(CEventContainer ob, byte[] arDest, int nIndex) { }


Зачем писать С в начале названия класса, если весь дотнет написан в нормальном, человеческом стиле? Ну это ещё ладно, это куда ни шло, хотя читать тяжко такое.

Название переменной ob - это вообще что за жесть? Почему не container? Дураку понятно, что это объект там будет на момент выполнения.

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

Собственно вы поняли, что устроился я на новую работу. Зарплата больше в 2 раза, чем на прошлой работе, только это держит. Ну и я не всемогущ, тоже мне есть чему учиться, к примеру, T-SQL нужно учить, работу с БД и много другого. То есть я не гений, но такие мелочи реально напрягают.

Кстати, это далеко не самое худшее. Самое худшее это жуткий ппц в виде ужасного оформления классов в разных стилях. Всё перемешано, где-то методы сверху, конструктор посередине, поля вообще везде разбросаны. Где-то каждое поле свойства над свойством вплотную, этот ад вообще тяжело читать. Нафига хранить поле рядом? Ну напиши ещё в комментариях в какой папке лежит этот класс тогда до кучи. Над методами простые комментарии, а не XML или их вообще нет, но зато всё описано в документации с ужасными названиями документов, ориентироваться в них очень непросто, но можно. В разных классах разные отступы. Почти все классы в основном проекте лежат, никаких папок и соответствия им нэймспэйсов (за редким исключением). Названия файлов в проекте не соответствуют классам внутри них. Это реально ад! У меня нет слов...

А у вас было подобное? Вы как-то решали эту проблему?
  • Вопрос задан
  • 2355 просмотров
Пригласить эксперта
Ответы на вопрос 5
ImmortalCAT
@ImmortalCAT
C# loving
хм
ед. что я слышал
  • все названия интерфейсов начинаются с заглавной I
  • все приватные элементы, первая буква прописной и '_' : _myYearsLength
  • все открытые - все первые буквы - заглавные MyLittleClass
  • в методах, перегрузки идут прописными
  • любые переменные в перегрузки указываются прописными буквами

не знаю на сколько это правильно, но я так использую
Ответ написан
Nipheris
@Nipheris Куратор тега C#
Для меня очевидно, что это писали бывшие разработчики на C/C++. Это древняя нотация, многие называют ее венгерской, только тут какой-то извращенный вариант (надо сказать, что и саму венгерку правильно применяли единицы в свое время, большинство не понимало до конца ее смысла). Сейчас так не пишут и на самих плюсах, для шарпа же это моветон. Выдает нотацию n перед именем индекса (это значит именно "индекс", а не int, правда обычно пишут nUnit или nEmployee, а не nIndex) и C перед именемами классов.
Если есть нормальная IDE, то венгерская нотация нафиг не нужна, код превращается в рябь из смеси сокращений, которые только раздражают

Совершенно согласен с вами.

Не такие уж опытные ребята писали этот код, и они точно не в ладах с оформлением кода в C#. Вероятно, писали давно, когда C# еще появился, и все C++ программеры начинали писать на нем, сохраняя все свои привычки, многие из которых не нужны или даже вредны.
То, что разные классы по-разному оформлены это не еще не большая беда, далеко не всем проектам удается поддержать одинаковый стиль (хотя оно того стоит конечно).
Почти все классы в основном проекте лежат, никаких папок и соответствия им нэймспэйсов (за редким исключением).

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

А это кроме вашей команды во главе с тимлидом и даже с привлечением менеджеров никому не решить. Если вы готовы отрефакторить половину продукта - вперед. Не готовы - лучше не трогайте. Пишите новый код в адекватном стиле. Если бы это был C++, я бы даже вам посоветовал новый код оформлять по правилам проекта, но ЭТИ правила в рамках C# неадекватны совершенно.

Резюмирую: если нет ресурсов на переработку кода - терпите. Терпение и способность работать с legacy кодом не самого высокого качества - вероятно самая важная черта "программиста в команде". Старый и не самый симпатичный код - это реальность, это так же реально, как и ветхие здания, которые просто так не перестроишь без серьезных вложений.
Работал в одной организации полтора года, написал сам несколько проектов. код в плане оформления просто чуть ли не идеален. Без всякой чуши типа венгерской нотации и т.д.

Вам везло в плане качества кода. Теперь не очень повезло. Как сказал AtomKrieg, хорошо что не Кобол (хотя б тогда вам платили еще больше).
Над методами простые комментарии, а не XML или их вообще нет

Нормальные XML-комментарии в C# коде это вообще роскошь. Я их вижу только в серьезных библиотеках, а во всяком корпоративном треше так комментятся только самые важные классы в программе (штук 10-15). Радуйтесь, что вообще есть документация. Если есть желание и время - переносите в код, это наверняка будет полезно.
Ответ написан
Комментировать
@nico
у меня на проекте тим лид ставит запятые в начале строки, типа
Method(int a
, int b
, int c)

хочется пристрелить. Я понимаю в SQL там так делают, чтобы по быстрому глянуть там данные, но в С# то чего глядеть?).
А еще никто не парится и пишут строки длиной в столько символов, сколько захочется. Я находил и по 400-500.
В общем я это все правлю когда работаю в методах с чужим кодом, но блин они снова пишут). Я спрашиваю, ребята, у вас мониторы 50 дюймов? Вы, bla, как просматриваете код, маслите мышкой туда-сюда? Смотрят на меня своими филлипинскими глазами в очках и улыбаются...
Ответ написан
@Taksist410
Главное чтоб код работал и архитектура былаб разумной. А как он оформлен это второй вопрос. Смысл в трудночитаемом коде тоже есть: его труднее украсть. Сам такой пишу, когда возвращаюсь со смены и устал. В конце концов в Visual Studio есть много хороших средств анализа кода.
Ответ написан
Комментировать
Codestyle
Visual Studio Code analysis rule set reference

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

Войдите, чтобы написать ответ

Похожие вопросы