Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Конвенция/стандарты кодирования C  (Прочитано 17291 раз)
0 Пользователей и 2 Гостей смотрят эту тему.
Nick
Интересующийся

ru
Offline Offline

« : 05-08-2015 14:56 » 

День добрый!
Интерисует следущие какой стандарт наибоелее предпочтителен в C и по чему.
Я смотрел Dennis Ritchie&Brian Kernighan,  но  ответа как-то не нашел

Мне показался удобным такой вариант:

/*******************************************************************
** Name:    MGCGILink
** Descr:    Inserts a url-style link in a web page
** Params:    URL = The url for the link
**            Text = Text that describes the URL.
** Returns: MGCGI_ERROK, or error code upon failure
** Author:    MG 10/9/97
** Type:    Output/Components and Controls
********************************************************************/
int MGCGILink( char *URL, char *Text )
{
    char *TmpText;
   
    if( (TmpText = MGCGIConvertToHTML( NULL, Text )) == NULL )
        return( MGCGI_ERRNOMEM );

    fprintf( MGCGIDest, "<A HREF=\"%s\">%s</A>", URL, TmpText );
    free( TmpText );
    return( MGCGI_ERROK );
}
Может быть кто-нибудь даст сцылочку на этот стандарт кодирования или может поделится своими предпочтениями





Записан
darkelf
Молодой специалист

de
Offline Offline

« Ответ #1 : 05-08-2015 15:22 » 

Если Вы про отступы, то, имхо, это похоже на стиль Олмана, а если про пробелы между скобками, то, к сожалению, такого стиля не знаю.
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 05-08-2015 21:24 » 

Следует различать разработку кода и оформление, это разные аспекты кодирования.

Если речь о разработке, для меня предпочтителен стандарт MISRA. Почему - следует из определения.

Если речь об оформлении, то объективных причин для выбора нет, это исключительно холиварное направление без малейшего конструктива. Опытные люди руководствуются железным правилом: не так уж важно, какой из вариантов будет выбран, главное, чтобы его придерживались все члены команды во всех файлах проекта. Мудрые люди вообще не заморачиваются подобными пустяками, поскольку пользуются инструментами наподобие GNU Indent, которые позволяют быстро оформить любой синтаксически корректный код на C в любом стиле. Отдайте тупую работу компьютеру и думайте о вещах, которые действительно стоит обдумывать.
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Nick
Интересующийся

ru
Offline Offline

« Ответ #3 : 11-08-2015 11:58 » 

2Dale, Спасибо. GNU Indent - попробовал, удобная утилита.
Просто хотелось понять как лучше документировать код.
Записан
RXL
Технический
Администратор

Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 11-08-2015 12:14 » 

Лучшая документация кода - читаемый код!
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #5 : 11-08-2015 18:09 » new

Просто хотелось понять как лучше документировать код.

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

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 11-08-2015 21:41 » 

Просто хотелось понять как лучше документировать код.

Тогда вы уж очень издалека зашли. Причем не у меня одного возникло такое впечатление:

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

Как общее правило воспользуйтесь советом RXL:

Лучшая документация кода - читаемый код!

Как способ достижения этой цели используйте концепцию "грамотного кодирования" Дональда Кнута. Помогут в выработке стиля также рекомендации Стивена Макконнелла ("Совершенный код" и др.), "дядюшки Боба" Роберта Мартина ("Чистый код" и др.) и множество других книг на эту тему, сейчас их предостаточно. Некоторые из них найдете на моей "Книжной полке".

Сторонники agile подхода считают, что очень хорошую документацию представляют собой тесты (особенно если разработка ведется через TDD/BDD/ATDD и иже с ними). Я с ними полностью солидарен.

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

Изучайте и применяйте паттерны. Они прекрасно документированы и известны профессионалам. Достаточно сказать "здесь использован паттерн такой-то", и можно дальше не комментировать, все и так понятно. Главное - применять их осознанно (иначе получится собачий цирк наподобие того, который недавно устроил один из новичков под видом паттерна "Декоратор").

Хороший тест на читаемость - ревизия кода опытными разработчиками, проверено лично на практике. Со стороны многие вещи гораздо виднее. Устраните все обоснованные замечания - и код примет совершенно другой вид.

Если посмотрите на проблему еще ширше, выяснится, что кодирование - не самая сложная часть разработки (как укладка кирпичей не есть суть архитектуры, хотя от качества укладки, конечно, сильно зависит качество здания в целом). Понадобится документировать не только сам код, но и требования заказчика, и архитектуру решения, которая должна обеспечить воплощение этих требований. Тут весьма кстати придется UML и архитектурная модель "4+1".

Остается для меня непознанным единственный вопрос: при чем тут Unix?
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines