У кого какие мнения на этот счет? Может, кто подобные ссылки подкинет (Хочется посмотреть на соглашения о кодировании известных проектов)?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Здравствуйте, np9mi7, Вы писали:
N>Добрый день!
N>Возникло желание обсудить http://www.mozilla.org/hacking/mozilla-style-guide.html#General;
N>У кого какие мнения на этот счет? Может, кто подобные ссылки подкинет (Хочется посмотреть на соглашения о кодировании известных проектов)?
В CodingStyle хорошо одно: то что он есть, какой именно в общем пофигу,
если конечно не брать крайние случаи типа MS$ кода.
Советую взглянуть на /usr/src/linux/Documentation/CodingStyle
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, <Аноним>, Вы писали:
А>>Советую взглянуть на /usr/src/linux/Documentation/CodingStyle CC>Мы глянем, ток ты б хоть в нет куда выложил...
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, <Аноним>, Вы писали:
А>>Советую взглянуть на /usr/src/linux/Documentation/CodingStyle CC>Мы глянем, ток ты б хоть в нет куда выложил...
Здравствуйте, <Аноним>, Вы писали:
А>В CodingStyle хорошо одно: то что он есть, какой именно в общем пофигу, А>если конечно не брать крайние случаи типа MS$ кода.
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Re[3]: C/C++ Coding Style
От:
Аноним
Дата:
03.08.06 13:59
Оценка:
Здравствуйте, np9mi7, Вы писали:
N>Здравствуйте, <Аноним>, Вы писали:
А>>В CodingStyle хорошо одно: то что он есть, какой именно в общем пофигу, А>>если конечно не брать крайние случаи типа MS$ кода.
N>А что не так в M$ коде? Вроде Hungarian Notation...
Проилиструем мой ответ кодом notepad,
1)большинство функций не интуитивно понятны, это губительно для общего API,
никогда не делаете так в своих проектах!!
// bugbug
// for some reason, this procedure tries to maintain
// a valid 'fp' even though I believe it does not need
// to be.
// bugbugvoid FileDragOpen(void)
{
HANDLE oldfp;
oldfp= fp; // remember in case of errorif( CheckSave(FALSE) )
{
fp= CreateFile( szPath, // filename
GENERIC_READ, // access mode
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL, // security descriptor
OPEN_EXISTING, // how to create
FILE_ATTRIBUTE_NORMAL,// file attributes
NULL); // hnd to file attrs
приходится коментировать вызов функции отрытия файла, почему?
потому что через 10 секунд вы забываете, зачем же нужны эта сотня параметров.
2)Для всех типов придуманны новые а-ля M$ названия, нахрена? имеет смысл только
если вы хотите добиться одного размера на разных платформах,
но скажем void имеет разные размер?
/* ** Enable or disable menu items according to selection state
This routine is called when user tries to pull down a menu. */
VOID NpResetMenu( HWND hwnd )
{
Остальное конечно личное и к делу не относиться,
типа использование Pascal style, в коде на С
VOID FAR InsertDateTime (BOOL fCrlf)
{
SYSTEMTIME time ;
TCHAR szDate[80] ;
TCHAR szTime[80] ;
DWORD locale;
locale= MAKELCID( MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), SORT_DEFAULT) ;
// Get the time
GetLocalTime( &time ) ;
или не использование собственных инструментов для сборки:
$ cat makefile
#
# DO NOT EDIT THIS FILE!!! Edit .\sources. if you want to add a new source
# file to this component. This file merely indirects to the real make file
# that is shared by all the components of NT OS/2
#
!INCLUDE $(NTMAKEENV)\makefile.def
а почему не VS, потому что она сдохнет на сборке и работе с большими проектами?
А>1)большинство функций не интуитивно понятны, это губительно для общего API, А>никогда не делаете так в своих проектах!!
Думаю, что код Notepad-а как раз не показателен вообще!
Советую посмотреть код ядра. Вот его писали ОЧЕНЬ профессионально (где найти, не скажу... гугли — и будет тебе счастье) и
на такой код просто приятно читать
А>а почему не VS, потому что она сдохнет на сборке и работе с большими проектами?
Хмммм, странный вопрос ...
Давай различать СРЕДУ РАЗРАБОТКИ и СИСТЕМУ АВТОМАТИЧЕСКОЙ СБОРКИ
Я например, все части приложения пишу и вначале отлаживаю в VS, а потом добавляю в мейк файл, потому что одним запуском там проганяется всё — и сборка, и тесты. Некоторый юзают bjam, потому что там уже некоторый профиля настроенны(debug release) и не надо парится с подбором ключей ... А вообще это вопрос вкуса, а о вкусах , как известно, не спорят ...
Здравствуйте, <Аноним>, Вы писали:
А>2)Для всех типов придуманны новые а-ля M$ названия, нахрена? имеет смысл только А>если вы хотите добиться одного размера на разных платформах,
Смысл в том, чтобы отвязаться от конкретной реализации компилятора и при необходимости изменять используемые типы. Не говоря уж о том, что какой размер у int будет на следующей неделе предсказать ловольно трудно.
А>Остальное конечно личное и к делу не относиться, А>типа использование Pascal style, в коде на С
??? Что больше настолько не к чему придраться?
А>а почему не VS, потому что она сдохнет на сборке и работе с большими проектами?
Здесь может быть все что угодно, начиная с того, что никому не охота переделывать систему сборки(а некоторые исходные файлы датированы аж 1989 годом) просто из-за того, что под свое.
