Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
А ведь PS предупреждал... 17.10.02 18:43 Число просмотров: 1239
Автор: _Inquisitor_ Статус: Незарегистрированный пользователь
|
PS оказался прав на счет флейма :-(
Последняя пара мессаг, IMHO выражает личные предпочтения авторов
|
<programming>
|
требования к исходникам 17.10.02 12:05
Автор: ggg <ggg> Статус: Elderman
|
интересно, где-нибудь есть список требований к исходникам
типа чтобы их можно было считать прилично выглядящими
... или можно здесь совместными усилиями их родить :)
|
|
Дам почитать. 22.10.02 10:46
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
"С и С++ Правила программирования" Ален И. Голуб Под редакцией В. Костенко. БИНОМ 1996г. Издательство "Восточная Книжная Компания" 1996г. Тир. 11000. 270 страниц.
Подойдет для любого алгоритмического языка.
Описаны правила не только к тексту исходников, но и вплоть до корректности применения возможностей языка с целью минимизации багов.
Дам почитать.
|
|
а воз и ныне там 18.10.02 22:58
Автор: beetle <beetle> Статус: Member
|
> интересно, где-нибудь есть список требований к исходникам > типа чтобы их можно было считать прилично выглядящими > > ... или можно здесь совместными усилиями их родить :) соблюдать некоторые правила приличия - и все тут
имеется в виду правила приличия для исходников=))
отступы, пробелы, имена со смыслом,да и директивы IN,OUT,OPTIONAL
|
|
требования к исходникам 17.10.02 15:39
Автор: vim Статус: Незарегистрированный пользователь
|
> интересно, где-нибудь есть список требований к исходникам > типа чтобы их можно было считать прилично выглядящими > > ... или можно здесь совместными усилиями их родить :)
Я бы сказал они должны быть такими:
1. Имена функций и переменных должны иметь смысловое значение.
Например, вместо i должно быть index.
Запрещается использовать короткие имена.
Исключение соствляют небольшие циклы на 2-3 строки кода
где допустимо использовать короткие переменные, например
for(int i = 0; i < N i++)
{
Sum = Sum + x[i];
}
2. Переменные-члены класса должны иметь особое название,
к примеру, начинаться с m_ (как это принято в MFC)
3. Не писать выражения слитно. Всегда ставить между операндами пробелы. Это повышает читабельность кода.
Плохой пример: x=2*getPos(px/2);
Хороший пример: x = 2 * getPos( px / 2 );
4. Строго соблюдать отступы.
5. Для большинства функций всегда делать шапку с комментариями
*********** Name:
Parameters:
Return value:
Description:
*********
Исключение составляют небольшие функции
в которых по названию понятно что они делают.
6. Писать комментарии в коде.
Программа всегда читается по комментариям.
7. Писать не более одного выражения в строке.
Например, недопускаются выражения типа
while (f = getValue() != 0)
8. Не использовать оператор ++ (--) внутри выражения
Вроде так
|
| |
не совсем согласен. 17.10.02 15:59
Автор: PS <PS> Статус: Elderman
|
> 1. Имена функций и переменных должны иметь смысловое > значение. > Например, вместо i должно быть index. > Запрещается использовать короткие имена.
не совсем так. просто index говорит так же мало как и i. желательно писать index_of_...
> > Исключение соствляют небольшие циклы на 2-3 строки кода > где допустимо использовать короткие переменные, например > > for(int i = 0; i < N i++) > { > Sum = Sum + x[i]; > }
вместо i все же лучше использовать idx. и еще: избегайте определения переменной в for(). разные компиляторы по разному определяют область видимости.
> > 2. Переменные-члены класса должны иметь особое название, > к примеру, начинаться с m_ (как это принято в MFC) > > 3. Не писать выражения слитно. Всегда ставить между > операндами пробелы. Это повышает читабельность кода. > > Плохой пример: x=2*getPos(px/2); > Хороший пример: x = 2 * getPos( px / 2 ); > > 4. Строго соблюдать отступы. > > 5. Для большинства функций всегда делать шапку с > комментариями > *********** > Name: > Parameters: > Return value: > Description: >**********
это лучше делать в хидере. VC берет такой "заголовок" из .h файла и показывает как коментарий в спадающем списке ф-ий.
> > Исключение составляют небольшие функции > в которых по названию понятно что они делают. > > 6. Писать комментарии в коде. > Программа всегда читается по комментариям.
не всегда. ваш покорный слуга предпочитатет читать код ;)
> > 7. Писать не более одного выражения в строке. > Например, недопускаются выражения типа > while (f = getValue() != 0)
а так же ставить скобки: while ( ( f = getValue() ) != 0)
> > 8. Не использовать оператор ++ (--) внутри выражения
А это еще почему ?
|
| | |
не совсем согласен. 17.10.02 17:40
Автор: ggg <ggg> Статус: Elderman
|
> > Например, вместо i должно быть index. > > Запрещается использовать короткие имена. ну для i,j,k можно сделать исключение - к этому уже все привыкли
просто если переменная часто используется, то дллинное имя тоже не есть хорошо, так как увеличивает размер кода, а значит ухудшает читабельность
> > 2. Переменные-члены класса должны иметь особое > название, > > к примеру, начинаться с m_ (как это принято в MFC) это согласен
я ещё глобальным/статическим переменным прибавляю g_/s_
> > 3. Не писать выражения слитно. Всегда ставить между > > операндами пробелы. Это повышает читабельность кода. > > Плохой пример: x=2*getPos(px/2); > > Хороший пример: x = 2 * getPos( px / 2 ); тоже не всегда
длинная строка трудно читается
лучше отделять пробелами большие блоки в выражениях
> > 5. Для большинства функций всегда делать шапку с > > комментариями оно конечно хорошо...
только:
1) отнимает время,
2) нужно знать английский, потому что кривой язык не очень украсит исходники (в принципе можно и на русском, если исходники для себя)
на практике получается делать комментарии для больших функций, которые не планируется никогда менять, или которыми будут пользоваться посторонние люди
> > 7. Писать не более одного выражения в строке. > > Например, недопускаются выражения типа > > while (f = getValue() != 0) если выражение не сложное, почему бы и нет?
меньше строк будет
и потом как ты заменишь такую конструкцию:
char c;
while( (c=GetNextChar())!=0 ) // кстати пример с пробелами
{
...
};
|
| | | |
не совсем согласен. 17.10.02 20:44
Автор: vim Статус: Незарегистрированный пользователь
|
> > > Например, вместо i должно быть index. > > > Запрещается использовать короткие имена. > ну для i,j,k можно сделать исключение - к этому уже все > привыкли > просто если переменная часто используется, то дллинное имя > тоже не есть хорошо, так как увеличивает размер кода, а > значит ухудшает читабельность
Да, согласен, но это должно быть в пределах небольшого фрагмента кода, скажем в пределах одного экрана.
Потому что если цикл большой, на несколько экранов, то можно просто запутаться в этих переменных.
> > > 2. Переменные-члены класса должны иметь особое > > название, > > > к примеру, начинаться с m_ (как это принято в > MFC) > это согласен > я ещё глобальным/статическим переменным прибавляю g_/s_ > > > > 3. Не писать выражения слитно. Всегда ставить > между > > > операндами пробелы. Это повышает читабельность > кода. > > > Плохой пример: x=2*getPos(px/2); > > > Хороший пример: x = 2 * getPos( px / 2 ); > тоже не всегда > длинная строка трудно читается > лучше отделять пробелами большие блоки в выражениях > > > > 5. Для большинства функций всегда делать шапку с > > > комментариями > оно конечно хорошо... > только: > 1) отнимает время, > 2) нужно знать английский, потому что кривой язык не очень > украсит исходники (в принципе можно и на русском, если > исходники для себя) > на практике получается делать комментарии для больших > функций, которые не планируется никогда менять, или > которыми будут пользоваться посторонние люди
В этом и отличие хорошего стиля от "простого".
> > > 7. Писать не более одного выражения в строке. > > > Например, недопускаются выражения типа > > > while (f = getValue() != 0) > если выражение не сложное, почему бы и нет? > меньше строк будет > > и потом как ты заменишь такую конструкцию: > char c; > while( (c=GetNextChar())!=0 ) // кстати пример с пробелами > { > ... > };
Не совсем понял в чем проблема ее заменить.
Можно например так:
char c;
while (1)
{
c = GetNextChar();
if (c == 0) break;
...
};
Просто по логике вещей в команде while(...) в скобках должна стоять проверка условия, а вместо этого туда вставляются команды, которые не имеют отношения к проверке условия.
Кроме того, это снижает читабельность кода. Чтобы понять его, ты мысленно "парсируешь" условие на собственно команду c = GetNextChar(), и затем с != 0.
Ну и, наконец, это просто повышает вероятность ошибки. Можно к примеру опустить скобку
while (c = GetNextChar() != 0)
тогда в переменную C может присвоиться результат вычисления логического выражения GetNextChar() != 0, или в будущем понадобиться второе условие сюда добавить.
Мое мнение - все конструкции должны быть простыми и понятными.
Это главный принцип.
По этой же причине я считаю недопустимо писать в выражениях ++ (--) так как это усложняет восприятие кода, и может стать потенциальным источником ошибок.
x = a + b * (--c) / (d++) ;
|
| | | | |
не совсем согласен. 17.10.02 21:42
Автор: ggg <ggg> Статус: Elderman
|
> > char c; > > while( (c=GetNextChar())!=0 ) // кстати пример с > пробелами > > { > > ... > > }; > > char c; > while (1) > { > c = GetNextChar(); > if (c == 0) break; > > ... > }; > на while(1) MSVC скажет warning: что то типа проверка постоянного выражения
тогда уж лучше for(;;)
и это получается 3 строки вместо одной, вобщем не такой уж и сложной для восприятия
тут уж наверно кому как больше нравится
кто к какому варианту больше привык
> Ну и, наконец, это просто повышает вероятность ошибки. > Можно к примеру опустить скобку > > while (c = GetNextChar() != 0) на это MSVC скажет warning: присваивание внутри условия
> Мое мнение - все конструкции должны быть простыми и > понятными. большое количество строк тоже может затруднить чтение программы, особенно большого проекта
некоторые непривычные конструкции могут сокращать текст программы
например:
if( (res=Func1(), !res)| (res=Func2(), !res)| (res=Func3(), !res) )
{
// Error
delete[] p1;
delete[] p2;
...
return;
};
если всё это расписывать, то займёт много места
|
| | | | | |
не совсем согласен. 18.10.02 01:23
Автор: vim Статус: Незарегистрированный пользователь
|
> > Мое мнение - все конструкции должны быть простыми и > > понятными. > большое количество строк тоже может затруднить чтение > программы, особенно большого проекта > > некоторые непривычные конструкции могут сокращать текст > программы > например: > if( (res=Func1(), !res)| > (res=Func2(), !res)| > (res=Func3(), !res) ) > { > // Error > delete[] p1; > delete[] p2; > ... > return; > }; > если всё это расписывать, то займёт много места
Не могу согласиться. Программа должна быть прежде всего читабельной.
Я бы категорически запретил использовать конструкции подобные приведенной выше.
А что если с таким кодом будет работать кто-то еще, кроме автора?
Поставь себя на его место.
Конечно, разобраться можно в любом коде, но зачем же делать сложно, когда можно сделать просто.
Даже если ты один пишешь код, то ты можешь сам наступить на эти грабли, если по прошествии 1-2 месяцев тебе придется заглянуть в уже забытый код.
Сложный код и не очевидные конструкции - это потенциальный источник багов в программе.
Основной принцип - должно быть ПРОСТО и ПОНЯТНО.
|
| | | |
ещё... 17.10.02 17:44
Автор: ggg <ggg> Статус: Elderman
|
закрывать блоки точкой с запятой :)
{};
if() {};
в случае с if смысл очевиден - чтобы случайно не прицепился else
в остальных случаях - для однообразности кода
|
| | | | |
А ведь PS предупреждал... 17.10.02 18:43
Автор: _Inquisitor_ Статус: Незарегистрированный пользователь
|
PS оказался прав на счет флейма :-(
Последняя пара мессаг, IMHO выражает личные предпочтения авторов
|
|
требования к исходникам 17.10.02 12:31
Автор: _Inquisitor_ Статус: Незарегистрированный пользователь
|
> интересно, где-нибудь есть список требований к исходникам > типа чтобы их можно было считать прилично выглядящими > > ... или можно здесь совместными усилиями их родить :)
Так, на вскидку...
1. Рекомендуемый размер функции = 1 экран
2. Легкочитаемость кода (о как завернул), т.е. не злоупотребляйте сложными конструкциями
3. комментарии к отдельным блокам (процедуры, функции) действие которых неочевидно
4. Давать интуитивно понятные имена переменным и функциям
например: User_Name, Pswrd: string; //соотв. имя пользователя и пароль
IsOnLine: boolean; //думаю понятно
function Get_User_Name.......//ф-ия возвращающая имя пользователя
Некоторые программеры используют т.н. венскую нотацию (вроде так она зовется) именования переменных. Т.е. перед именем переменной ставится дескритор ее типа.
sUser_Name, sPswrd - переменные типа строка
bIsOnLine - переменная булевого типа
ЗЫ Это мои личные принципы форматирования исходников и они не претендуют на истинность
|
| |
ещё добавлю 17.10.02 13:19
Автор: ggg <ggg> Статус: Elderman
|
1) размер файла не больше 20-30К
2) единый стиль имён (не менять его в разных частях исходников)
3) хорошо бы по имени отличать, например, функцию от переменной и другие объекты, но это уже что то типа венской нотации, и наверно не все согласятся (не обязательно буквы добавлять, можно большие и маленькие буквы различать)
|
|
Ты решил поднять грандиозный флейм ? 17.10.02 12:25
Автор: PS <PS> Статус: Elderman
|
Это же больная тема всех программистов !
Что-то мне подсказывает, что сейчас посыпиться...
Ладно, привожу пример, по моему разумению, "плохого" и "хорошего" исходника:
std::string HexToBuf(const std::string& hexString)
{
if (hexString.length() % 2 != 0 )
return "";//throw CException(BASIC_ERROR_LINE__,__FILE_"Wrong hex value: %s", hexString.c_str());
if (hexString.length() >= 1024)
return "";//throw CException(BASIC_ERROR_LINE__,__FILE_"Wrong hex value: %s", hexString.c_str());
char buf[1024];
memset(buf,0,sizeof(buf));
unsigned char* bb = (unsigned char*)buf;
for (unsigned int i = 0; i < hexString.length(); i += 2)
{
unsigned char c = hexString[i];
if (! isdigit(c) && ! ('a' <= c && c <= 'f') && ! ('A' <= c && c <= 'F'))
return false;
*bb = (isdigit(c) ? c - '0' :
((('a' <= c && c <= 'f') ? c - 'a' : c - 'A')) + 10) << 4;
c = hexString[i + 1];
if (! isdigit(c) && ! ('a' <= c && c <= 'f') && ! ('A' <= c && c <= 'F'))
return false;
*bb++ |= isdigit(c) ? c - '0' :
((('a' <= c && c <= 'f') ? c - 'a' : c - 'A') + 10);
}
return std::string(buf,hexString.length()/2);
}
---
void TCPConnector::Reader( void* _me )
{
while(1)
{
printf( "Reading a packet...\n" );
TCPConnector* me = (TCPConnector*)_me;
if( !me->m_reader_ready.Get() )
{
_beginthread( WaitForConnectReader, 0, _me );
return;
}
short packetSize;
int rcvSz;
if( ( rcvSz = recv( me->m_sock_reader, (char*)&packetSize, sizeof( short ), 0 ) ) != SOCKET_ERROR )
{
if( packetSize < 0 )
{
printf( "The packet size is (%X). Connect is broken !\n", packetSize );
closesocket( me->m_sock_reader );
me->m_reader_ready.Set( false );
_beginthread( WaitForConnectReader, 0, _me );
return;
}
if( packetSize == 0 )
{
printf( "The packet size is (%X) ! Skipping...\n", packetSize );
Sleep(1000);
_beginthread( Reader, 0, _me );
return;
}
}
else
{
printf( "The error while recive. The connect is broken !\n" );
closesocket( me->m_sock_reader );
me->m_reader_ready.Set( false );
_beginthread( WaitForConnectReader, 0, _me );
return;
}
char* buffer = new char[ packetSize ];
int recSize = 0;
int offset = packetSize;
int tmpPS = packetSize;
char *ptr = buffer;
while( recSize < tmpPS)
{
tmpPS -= recSize;
ptr += recSize;
offset -= recSize;
recSize = recv( me->m_sock_reader, ptr, offset, 0 );
if( recSize == SOCKET_ERROR )
{
printf( "The error while recive. The connect was broken !\n" );
closesocket( me->m_sock_reader );
me->m_reader_ready.Set( false );
_beginthread( WaitForConnectReader, 0, _me );
delete[] buffer;
return;
}
}
me->m_Reciver( buffer, packetSize );
delete[] buffer;
}// while(1)
}
---
Думаю комментарии излишни.
|
| |
3000 строк в "плохом" стиле 20.10.02 00:29
Автор: Killer{R} <Dmitry> Статус: Elderman
|
3000 строк в "плохом" стиле занимает у меня только один .cpp проекта. Если все это ремарками разбавить то раза в два как минимум добавится. Этож заснешь пока прочитаешь... Ж:-).
|
| |
Ты решил поднять грандиозный флейм ? 17.10.02 13:10
Автор: ggg <ggg> Статус: Elderman
|
на самом деле правил можно придумать не так уж и много
ведь никто не собирается навязывать свой стиль программирования
как я понял ты в примерах показал вот что:
1) в исходниках должен сохраняться единый стиль форматирования (отступы и т.п.)
2) стиль форматирования должен облегчать выделение взглядом отдельных конструкций
3) закомментированные куски кода нужно описывать (когда это не очевидно)
|
| | |
Все верно 17.10.02 14:46
Автор: PS <PS> Статус: Elderman
|
> как я понял ты в примерах показал вот что: > 1) в исходниках должен сохраняться единый стиль > форматирования (отступы и т.п.) > 2) стиль форматирования должен облегчать выделение взглядом > отдельных конструкций > 3) закомментированные куски кода нужно описывать (когда это > не очевидно)
4) Название переменных и функций должны называться так, что бы понять, для чего они предназначенны.
То что не смог сказать в исходнике:
Пара .cpp .h (.c .h) должна содержать один и только один логический модуль.
Отдельно стоящие ф-ии должны быть объединены либо в библиотеку, либо в файл utils.c (misc.c, ect.)
Каждый модуль должен предворяться шапкой с описанием для чего он предназначен.
Недопустимы #iclude в любом месте, кроме начала файла.
|
| | | |
по поводу стилей расставления скобок {} 17.10.02 23:33
Автор: fuckyoudude Статус: Незарегистрированный пользователь
|
Вот нарыл тут про стили расставления скобок, думаю будет недурно глянуть на стандарты :))
1.Стиль 1TBS (One True Bracing Style)
Им пользовались небезызвестные Керниган и Ричи в своей книжке.
Пример:
for(j=0; j<MAX_LEN; j++) {
foo();
}
плюсы: экономия вертикального пространства.
минусы: трудно , иногда, найти { :-)
2. Стиль Алмена.(стиль BSD)
Алмен - атор многих утилит для BSD - отсюда и название.
for (j=0; j<MAX_LEN; j++)
{
foo();
}
3. Cтиль Whitesmith
for (j=0; j<MAX_LEN; j++)
{
foo();
}
4. Стиль GNU.(3+2)
for (j=0; j<MAX_LEN; j++)
{
foo();
}
|
| | | | |
+ 19.10.02 23:13
Автор: Бяша <Biasha> Статус: Member
|
> Вот нарыл тут про стили расставления скобок, думаю будет
> недурно глянуть на стандарты :))
>
> 1.Стиль 1TBS (One True Bracing Style)
> Им пользовались небезызвестные Керниган и Ричи в своей
> книжке.
> Пример:
>
> for(j=0; j<MAX_LEN; j++) {
> foo();
> }
>
> плюсы: экономия вертикального пространства.
> минусы: трудно , иногда, найти { :-)
>
> 2. Стиль Алмена.(стиль BSD)
> Алмен - атор многих утилит для BSD - отсюда и название.
>
> for (j=0; j<MAX_LEN; j++)
> {
> foo();
> }
>
> 3. Cтиль Whitesmith
> for (j=0; j<MAX_LEN; j++)
> {
> foo();
> }
>
> 4. Стиль GNU.(3+2)
>
> for (j=0; j<MAX_LEN; j++)
> {
> foo();
> }
---
|
|
|