Друзья, поделитесь своими стилями оформления кода(я понимаю, что есть у каждого на работе свои доки по стилю, но все же интересно)
мне интересно как Вы оформляете коменты

Как то так. Не профессиональный программист, но, ИМХО, более менее читабельно получается.

1000000dollars, Кстати не все!
Я однажды для удобства, впихнул http запрос в код, чтоб в другое окно не переключаться. Долго я не мог понять почему часть из запроса, включалась в компиляцию. Так и не понял. Пришлось в другом окне читать  

MSVS 2008.

Вот:


Это сообщение отредактировал(а) andrew_121 - 30.6.2009, 18:25

K&R

Комменты... в коде... хм   

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

BSD
имена классов - с большой буквы, cammel case
имена переменных, методов, ф-ий - в нижнем регистре
имена констант, макросов - в верхнем регистре
имена закрытых переменных класса заканчиваются на _
отступ - 4 пробела, ворматирование пробелами

И почему же ?

Этот стиль отличается от Java-style только позицией { при классах и методах. Все остальное идентично.

Вот и мне любопытно.
На* пустые строки? Или ЗП от кол-ва строк расчитывается?

чисто субъективно - лучше читаемость





мне первый вариант как-то глаза мозолит.. 

Добавлено через 52 секунды
во втором варианте проще находить начало блока, если находишься в его конце, так как скобки имеют один уровень отступа

Издеваешься ? там пять тыщ строк   
Хотя если нормально смотреть, в виме к примеру, то можно разобраться 

Добавлено через 2 минуты и 25 секунд
Lazin, 



1. K&R is right
2. K&R is right

Добавлено через 2 минуты и 59 секунд

  

 А это не ты ли писал, что на питоне пробовал писать?)
Если ты, то обманул таки )

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

это кусок исходного текста ядра Linux. Оно написано на Си. В Си нет классов. Если каждый файл там разбивать на мелкие по 200 строк, то файловая система умрет при распаковке.

там таких проблем нет, потому-что нет скобок xD

сравни с этим и представь, что кода больше.. его намного больше!!  



  
короче я ничего не понял, что ты хочешь этим сказать...

в общем, это дело вкуса..

Lazin, 
Любой уважающий себя редактор подсвечивает конец блока....

Установите табуляцию 2-3 и блок будет выделяться.

Это ты плохой  
Какие классы?!!! Это С !

табуляция в 2-3 пробела? что там будет выделяться кроме попытки выделяться?  

 О да, пусть будет на 2 минуты быстрее у юзверей распаковываться, чем читаться нормально.

 Т.е. ты сам признал, что код на C плохо читаем?) Просто помню, ты о C++ говорил, что это лишь синтаксический сахар ;)


"{" == ":"
"}" == ""(пусто)
т.е. код такой же, как в питоне, если считать скобки пустым местом, а смотреть лишь на строки.





Сравни ) P.S. синтаксис не приводил )
Мне второй вариант больше нравится - он компактнее, а на скобки никогда внимания не обращаю, смотрю лишь на реализуемые отступы.
Если же при { будет пустая строка, то кажется, как будто блок закончен, что не так )

Прикольная фраза получилась  


nerezus, Ты случаем не мусар? Помнишь что Лазин когда-то где-то писал, и за мной следишь? Неа, скорее ты извращенец.  



Да еще и зануда.

GrayCardinal, 
не, я про одну функции calc_delta_mine ;)

по сабжу мой выбор linux/Documentation/CodingStyle
по работе так

embedded С++. Мы руководствуемся MISRA - очень грамотная вещь.

Из такого что быстро приходит на ум - запрещено использование табуляторов - пробелы. Комменты в стиле doxygen.

Запрещено использование STL и эксепшнов, единый выход из функции, лимит на глубину колво скопов в функции, лимит на длину строки кода, запрет continue, оператора запятая. Нет пробела между именем функции и открывающей скобкой при вызове. Нет пробелов перед запятыми и точками, точками с запятой. Запрещены куски заремаренного кода (золотое с моей точки зрения правило). Один класс - cpp + hpp файл.

Я лично предпочитаю стиль
if (X)
{
   f();
} else
{
   f();
}

Кажется более интуитивно понятным

Это сообщение отредактировал(а) proc_maker - 18.8.2010, 16:42

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

Странная тема ... ну вот как я оформляю... (у меня очень мало комментариев)

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



continue тоже лечится таким же образом:



Как в половой жизни - раз приучил себя не писать как попало - и дальше не имеешь лишней головной боли разного рода.

Добавлено через 8 минут и 24 секунды


мы пишем так:

for (int i = 0; tempTree->Count > i; ++i)

А еще у нас скобки обязаны быть во всех if while case etc.
if ()
{
   a = 0;
}

Это сообщение отредактировал(а) proc_maker - 18.8.2010, 14:19

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

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

А какое отношение к оператору  goto ?

>> а потом ищешь где у тебя функция зависла и за того что стоит бесконечный цикл.
А где тут бесконечный цикл кстати? 



Запрещено.

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

Это сообщение отредактировал(а) proc_maker - 19.8.2010, 10:17

а что за конструкция такая с while(0); ?

может вместо 


проще написать


Это сообщение отредактировал(а) Dem_max - 19.8.2010, 11:33

Да, только чтобы юзать break он должен быть внутри цикла - иначе придется использовать return или goto. Вот while(0) и позволяет это делать не прибегая к циклу как к таковому 

просто жесть

proc_maker, то, что вы написали - не codestyle, а идея ради идеи. Зачем одни лаконичные конструкции заменять другими радутыми, но функционально эквивалентными?

Ня! (вариант для командной разработки).