информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsАтака на InternetSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Дам почитать. 22.10.02 10:46  Число просмотров: 1291
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
"С и С++ Правила программирования" Ален И. Голуб Под редакцией В. Костенко. БИНОМ 1996г. Издательство "Восточная Книжная Компания" 1996г. Тир. 11000. 270 страниц.
Подойдет для любого алгоритмического языка.
Описаны правила не только к тексту исходников, но и вплоть до корректности применения возможностей языка с целью минимизации багов.
Дам почитать.
<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();
> 	}

---
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach