powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сертификация и обучение [игнор отключен] [закрыт для гостей] / Правила кодирования! Именование, форматирование, читаемость ...
4 сообщений из 4, страница 1 из 1
Правила кодирования! Именование, форматирование, читаемость ...
    #33243780
Фотография denis1981
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Правила кодирования! Вопрос возник после прочтения опыта программистов, у которых на собеседовании просили показать пример кода.

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

Думаю, есть некий базовый набор рекомендаций!
Вот, мечтал почитать статьи на эту тему!
Было бы интересно ознакомиться с практическим опытом коллег по данному вопросу!

http://rusdeveloper.narod.ru - программист в Калуге - поддержка и продвижение сайтов
...
Рейтинг: 0 / 0
Правила кодирования! Именование, форматирование, читаемость ...
    #33314846
Фотография denis1981
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Уважаемые, модераторы! Прошу перенести мою тему в раздел вашего форума - Net.C#. Т.к. мой интерес и опубликованные данные относятся в первую очередь к C#. Заранее спасибо!

"Рекомендации по изобретению имен" из книги по C# - http://blaga.ru/Cbook/gl3/gl3.html#19
Жаль, что ссылки на страницы "Материалы о венгерской нотации" и "Техника паскаль и верблюд для C#" некорректны. Что-то еще я читал у Шилдта "Теория и практика программирования на C++". Интересно почитать еще материалы.

Рекомендации по изобретению имен

По статистике наибольшие затраты, связанные с разработкой приложений, приходятся на его сопровождение. Прежде чем мы продолжим, мне хотелось бы рассказать о соглашениях по составлению имен, поскольку от простоты и понятности такого соглашения может зависеть читабельность и, следовательно, удобство сопровождения кода. Многие из нас знают, что соглашения об именах — болезненная тема. Этот вопрос решался проще, пока не появились Visual C++ и MFC. Впервые я столкнулся с этой проблемой, когда группа, в которой я был ведущим разработчиком, получила задание создать первое в нашей компании Peachtree Software бухгалтерское приложение в среде MFC. Это было одно из тех собраний в самом начале проекта, когда все рвутся вперед и готовы, не жалея сил, идти до конца, в отличие от стадии завершения проекта, когда остается единственное желание — побыстрее сплавить эту проклятую программу. Разработчики шли плотным строем, глаза блестят — было ясно, что ребята готовы ринуться вперед. Что мне оставалось делать перед угрозой предстоящего кровавого побоища? Я сделал ход конем! Я решил, что, поскольку многое из MFC проникло в код Microsoft, мы должны использовать соглашения об именах Microsoft, принятые при создании MFC. В конце концов было бы весьма неразумно иметь две системы наименований в исходном коде: одну для MFC и другую для себя. Конечно, тот факт, что мне нравится венгерская нотация, даже и не затрагивался. Однако сейчас другое время, и в лице С# мы имеем новый язык и новые задачи. В этой среде мы не видим кода Microsoft. Более того, после многих разговоров в Microsoft с группой проектировщиков С# я понял, что появляется некий стандарт. Возможно, он будет отличаться от того, что я представляю здесь, но это хотя бы даст вам точку опоры.

Стандарты соглашения по назначению имен

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

Венгерская нотация

Венгерскую нотацию использует большинство разработчиков на С и C++ (включая и М1сго5ой'овцев). Эта система формирования имен создана сотрудником Microsoft Чарльзом Симони (Charles Simonyi). В начале 1980-х Microsoft приняла на вооружение систему, основа которой взята из докторской диссертации Симони "Meta-Programming: A Software Production Method" ("Мета-программирование: способ производства программного обеспечения").
Согласно венгерской нотации к имени переменной добавляется приставка, показывающая ее тип. Однако не каждый тип имеет свой стандартный префикс. Кроме того, появление новых языков и новых типов требует создания новых приставок. Поэтому немудрено, что со временем мы станем сталкиваться с префиксами, которые никогда нам раньше не встречались. (Между прочим, термин "Венгерская нотация" как бы показывает, что префиксы делают переменные такими, как будто они написаны на языке, отличном от английского; к тому же г-н Симонии родом из Венгрии.) Возможно, наиболее важной публикацией, агитирующей в пользу венгерской нотации, была первая книга, которую прочитал почти каждый разработчик под Windows и OS/2. Это книга Чарльза Петцольда (Charles Petzold) "Programming Windows" (Microsoft Press), в которой один из диалектов венгерской нотации применяется во всех демонстрационных приложениях. Более того, и Microsoft пользуется этой системой обозначений в собственных разработках. С MFC родилась очередная серия специфичных для C++ префиксов, продлив жизнь венгерской нотации. Так почему бы и нам не продолжить применение венгерской нотации? Тем более что эта система обозначений удобна в ситуациях, где желательно знать тип и/или область видимости применяемой переменной. Однако, как вы узнаете в главе 4, все типы в С# являются объектами и основаны на .NET-классе System.Object. Поэтому все переменные имеют основной набор ункциональных возможностей и поведенческих характеристик. Поэтому венгерская нотация в среде .NET теряет свою привлекательность.
ПРИМЕЧАНИЕ Любопытные и те, кто страдает от бессонницы, могут почитать материалы о венгерской нотации по адресу http://msdn.microsqft.com/library/techart/hunganotat.htm

Стили "Паскаль" и "верблюд"

Разработчики С# не связаны "жестким" стандартом, но из уже созданного ими видно, что они следуют набору условных обозначений, придуманных сотрудником Microsoft Робом Кэроном (Rob Caron), предложившим при обозначении переменных использовать смесь техник "Паскаль" и "верблюд". В статье "Coding Techniques and Programming Practices" ("Технологии и практика программирования"), имеющейся в MSDN ( http://msdn.microsoft.com/library/techart/cfr.htm ), он предлагает для имен методов применять технику "Паскаль", где первый символ изображается прописной буквой, и для имен переменных — технику "верблюд". В демо-приложениях этой книги я так примерно и поступаю. Поскольку же в С# есть не только переменные и методы, в следующих разделах вы найдете перечень других элементов языка и соответствующих им нотаций.

ПРИМЕЧАНИЕ: Дополнительные сведения по этой теме см. в руководстве по .NET Framework, включенному в документацию по .NET Framework SDK, в разделе .NET Framework Developer Specificati-ons\.NET Framework Design Guidelines\Naming Guidelines.

Пространства имен

Название пространства имен должно соответствовать имени вашей компании или названию программы, и первая буква должна быть прописной, например, Microsoft. Если же вы занимаетесь распространением компонентов
ПО, назовите пространство имен верхнего уровня именем вашей компании, а для каждого продукта создайте пространство имен следующего уровня со своими вложенными типами, исключив тем самым конфликты имен с другими продуктами. Пример тому есть в .NET Framework SDK: Microsoft. Win32. Такая техника приводит к нескончаемым цепочкам имен, однако благодаря директиве using пользователям вашего кода не придется вводить их целиком. Так, если компания Trey Research распространяет два продукта — электронную таблицу
(grid) и базу данных (database), пространства имен будут иметь названия Тгеу-Research.Grid и Trey Research. Database.

Классы

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

Методы

Применяйте технику "Паскаль" для всех методов. От методов ожидают выполнения некоей работы. Поэтому пусть в именах методов отражается то, что они делают. Например, Printlnvoice или OpenDatabase. Если методы предполагается использовать в булевских выражениях, добавьте к имени метода глагол, указывающий на то, что метод будет делать. Например, если метод будет возвращать булевское значение, определяемое блокировкой рабочей станции, назовите метод вроде IsWorkStationLocked. Тогда при
использовании метода в условном операторе его назначение будет понятнее, например:

if (IsWorkStationLocked) ...

Аргументы метода

Применяйте технику "Паскаль" для всех аргументов. Называйте аргументы выразительно, чтобы при работе IntelliSense пользователь мог сразу понять, для чего нужен каждый аргумент.

Интерфейсы

Применяйте технику "Паскаль" для всех интерфейсов. Стало традицией добавлять к имени интерфейса прописную букву "I", например, Кот-рагаЫе. (Это соглашение, пожалуй, единственное в С#, хоть как-io соответствующее венгерской нотации.)
Многие разработчики применяют одни и те же правила формирования имен и для интерфейсов и для классов. Однако между этими элементами существует фундаментальное философское различие. Классы представляют собой инкапсуляцию данных и функций, работающих с этими данными. Интерфейсы же представляют поведение объекта. Делая реализацию интерфейса, вы заявляете о готовности некоего класса продемонстрировать такое поведение. Поэтому в именах интерфейсов принято употреблять имена прилагательные. Например, интерфейс, объявляющий методы упорядочения данных, можно назвать таким образом: ISerializable.

Члены класса

Для разработчиков на С# это, пожалуй, самый неприятный вопрос. Те, кто работал с C++ и MFC, привыкли добавлять к именам членов приставку т_. Однако я советую вам обратиться к технике "верблюда", в которой первая буква не является прописной. Если у вашего метода есть аргумент Foo, то согласно этой технике вы сможете отличить его от внутреннего представления переменной, создав внутренний член/оо. Не стоит добавлять к имени переменной имя класса. Пусть, например, есть класс Author. Можно создать член этого класса с именем Author-Name, но тогда его полное имя будет Author.AuthorName. Тогда как достаточно назвать этот член просто Name.
...
Рейтинг: 0 / 0
Правила кодирования! Именование, форматирование, читаемость ...
    #33314883
Фотография denis1981
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нашел статью Rob Canon "Coding Techniques and Programming Practices"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/cfr.asp
...
Рейтинг: 0 / 0
Правила кодирования! Именование, форматирование, читаемость ...
    #33400434
Guest222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно прочитать Макконела Совершенный код. Интересная весчь, ИМХО;-))
Правда, касается не только программирования в тональности До-диез ))
...
Рейтинг: 0 / 0
4 сообщений из 4, страница 1 из 1
Форумы / Сертификация и обучение [игнор отключен] [закрыт для гостей] / Правила кодирования! Именование, форматирование, читаемость ...
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]