информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsСетевые кракеры и правда о деле ЛевинаЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 С наступающим 
 Серьезная уязвимость в Apache Log4j 
 Крупный взлом GoDaddy 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
3000 строк в "плохом" стиле 20.10.02 00:29  Число просмотров: 1031
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
3000 строк в "плохом" стиле занимает у меня только один .cpp проекта. Если все это ремарками разбавить то раза в два как минимум добавится. Этож заснешь пока прочитаешь... Ж:-).
<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-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach