ReSQL.ru
     
powered by simpleCommunicator - 2.0.38     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Соглашения о стандартах кодирования
21 сообщений из 21, страница 1 из 1
Соглашения о стандартах кодирования
    #36914974
Фотография kolesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kolesov
Участник
Коллеги, кому не жалко... поделитесь вашими соглашениями о кодировании в каше... Я о правилах именования, комментирования и проч.и проч. У нас тоже такое есть... но оно в офисе, а я - нет ;)
...
Рейтинг: 0 / 0
22.10.2010, 16:05
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915099
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
kolesovподелитесь вашими соглашениями о кодировании в каше...
Используем вот это...

автор Рекомендации по оформлению текста программ.

1. Заголовок программы.
В комментарии заголовка программы необходимо указать ее
автора и назначение, разделяя эти данные символом ";".

2. Метки.
Строка, содержащая метку, должна быть снабжена комментарием,
начинающимся следом за меткой. В комментарии следует указать
краткое назначение данной функции или процедуры. Никаких других
операторов в этой строке быть не должно. Удобно, когда название
метки отражает назначение данной функции или процедуры. По этому,
не стоит экономить на его длине. Без фанатизма разумеется...

3. Комментарии.
Все комментарии должны начинаться с новой строки. Следует
описывать в комментариях назначение данной функции или процедуры,
смысл параметров и основных переменных. Желательно отмечать
комментариями смысловые блоки в программах.

4. Строки программы.
Текст программы становится более "читабельным", если ее
строки не громоздки и замкнуты по смыслу. Стоит объединять строки
определенного назначения в процедуры или функции, снабжая их
соответствующим комментарием. Текст программы не должен сливаться с
имеющимися комментариями.

Стараться придерживаться правил:
* одна строка - один оператор;
* использовать только простые условия, сложные условия заменять
функцией и снабжать коментариями;
* не допускать сложновычисляемых операций в одной строке;
* вся строка должна помещаться на экране редактора.

5. Имена переменных, команд, процедур и функций.
Для упрощения чтения текста программ договоримся имена
параметров процедур и функций и названия внешних функций начинать
с больших букв, а в качестве остальных букв использовать только
маленькие; все прочие имена переменных писать только маленькими
буквами; имена процедур писать только большими буквами.
Заранее оговаривать имена основных переменных в задачах.

Пример оформления программы:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
EXAMPLE ;Иванов И.И.;ПРИМЕР ОФОРМЛЕНИЯ;;[  17 / 05 / 95   14 : 03  ]
Summa(Base,Field)                       ; Подсчет суммы значений полей
 n summa,urn
 ; Base  - имя базы
 ; Field - имя поля
 S summa= 0 
 S urn=""
 F  S urn=$O(^B(Base,urn)) Q:urn=""  D ADD
 Q summa
ADD                                    ; Добавить очередное значение
 n zn
 ; zn - значение в текущей записи
 S zn=$G(^D(urn,Field))  
 Q:zn> 1000 !'zn
 S summa=summa+zn 
 Q


Но всегда готовы расширить список дельными предложениями и замечаниями...
...
Рейтинг: 0 / 0
22.10.2010, 16:48
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915173
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Будете улыбаться, но в одной фирме видел в стандартах кодирования "никаких фигурных скобок, за них по рукам бить", в другой в точности наоборот - "только фигурные скобки и новые команды типа while, за точки по рукам бить".
...
Рейтинг: 0 / 0
22.10.2010, 17:21
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915495
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
ну я , у нас все требую делать на "именных" процедурах или функциях. Т.е. никакого "визуального" вложения. Фигурные скобки допускаются... Но внутри не более 1-2 строки.
Типа такого:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
DATA(Name) ; Преобразование данных
 s uz=""
 do {
    s uz=$o(@Name@(uz))
    d:uz'="" UZ
 } while uz'=""
 q
UZ ; Какие-то действия с данными
 q

Но каждая контора в праве сама решать какие у неё будут правила написания кода. Главное чтобы они были и соблюдались...
...
Рейтинг: 0 / 0
22.10.2010, 21:32
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915529
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Кстати, а почему так много людей делает блоки в стиле
Код: plaintext
1.
2.
3.
if че-то там много чего {
    тут че-то делаем
    и тут делаем
}
нифига ж непонятно? А если они многоуровневыми будут? брр.

мне кажется, что так было бы нагляднее, но многих этот стиль напрягает.
Код: plaintext
1.
2.
3.
if че-то там много чего 
   {тут че-то делаем
    и тут делаем
   }
Откуда идут разные традиции? Это сродни ctrl+shift и alt+shift, но про переключения языка я понимаю, откуда ноги растут, а в скобках нет.
...
Рейтинг: 0 / 0
22.10.2010, 22:30
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915709
ser_shu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ser_shu
Гость
Блок А.Н.Кстати, а почему так много людей делает блоки в стиле
Код: plaintext
1.
2.
3.
if че-то там много чего {
    тут че-то делаем
    и тут делаем
}
нифига ж непонятно? А если они многоуровневыми будут? брр.

мне кажется, что так было бы нагляднее, но многих этот стиль напрягает.
Код: plaintext
1.
2.
3.
if че-то там много чего 
   {тут че-то делаем
    и тут делаем
   }
Откуда идут разные традиции? Это сродни ctrl+shift и alt+shift, но про переключения языка я понимаю, откуда ноги растут, а в скобках нет.
Этот феномен наблюдаю много лет и объясненья ему нет. (И расклад почти пополам).
Примерно как Тупоконечники и Остроконечники - война на смерть.
Маниакально реинжинирят коды, переставляя блоки, скобки...
Единственное решение - принятие стандарта оформления кода. Решением начальника.
После этого все оставшиеся пишут и реинжинирят одинаково и никогда не поднимается этот вопрос.
Потому что, когда стиль одинаковый, всем становится проще работать.
...
Рейтинг: 0 / 0
23.10.2010, 08:11
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915718
Onix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Onix
Гость
Еще я бы добавил в коментарий тип, что это, процедура или функция или смесь, примерно так:
label1(pars,...) ;##; процедура, ...ля-ля-ля...
...
quit
;
label2(pars,...) ;$$; функция....
...
quit rezult

label3(pars...) ;#$; зависит от контекста вызова, вертаем значение или
; или просто выход //
i $q quit result
quit
...
Рейтинг: 0 / 0
23.10.2010, 09:05
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915738
ser_shu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ser_shu
Гость
Блок А.Н.Кстати, а почему так много людей делает блоки в стиле
Код: plaintext
1.
2.
3.
if че-то там много чего {
    тут че-то делаем
    и тут делаем
}
нифига ж непонятно? А если они многоуровневыми будут? брр.
можно сказать, что визуально закрылась строка с командой if, со всеми вложениями.
В SAMPLES класс Cinema.Utils именно такой синтаксис показывается, может с примеров от Интерсистемз и поехало.
...
Рейтинг: 0 / 0
23.10.2010, 10:02
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915888
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Ага, это еще туда-сюда, если блоки не разъехаись
А если отступы блоков поплыли, что вообще хрен поймешь какая скобка от чего.
...
Рейтинг: 0 / 0
23.10.2010, 14:38
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915943
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Блок А.Н.Кстати, а почему так много людей делает блоки в стиле
Код: plaintext
1.
2.
3.
if че-то там много чего {
    тут че-то делаем
    и тут делаем
}
нифига ж непонятно? А если они многоуровневыми будут? брр.
Например я поборник такого оформления. Но!
- не допускается "че-то там много чего" в самом условии
- не допускается "много чего", а так же вложений в самих "нутрях"

Потому как не "крадётся" еще одна строка как во втором твоём примере.
...
Рейтинг: 0 / 0
23.10.2010, 15:49
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915946
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
ser_shuЭтот феномен наблюдаю много лет и объясненья ему нет.
Моё объяснение подойдёт? Это чистая экономия одной строки... Потому как вот так

Код: plaintext
1.
2.
3.
if че-то там много чего 
   {тут че-то делаем
    и тут делаем
   }

некрасиво... А так

Код: plaintext
1.
2.
3.
4.
if че-то там много чего 
   {
    тут че-то делаем
    и тут делаем
   }

теряется одна строка...
...
Рейтинг: 0 / 0
23.10.2010, 15:52
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915952
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Да и скобка закрывается в обойх примерах некрасиво... Мне больше нравится иметь её прямо под открывшим её оператором

Код: plaintext
1.
2.
3.
if условие {
   тут че-то делаем
   и тут делаем
}

так например удобнее смотреть...

Ну это все моё мнение конечно. Хотя у себя заставляю этому следовать всех.
...
Рейтинг: 0 / 0
23.10.2010, 15:54
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915979
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Код: plaintext
1.
2.
3.
if че-то там много чего 
   {тут че-то делаем
    и тут делаем
   }
А че это некрасиво?
На мой взгляд, тело блока должно быть прижато к его началу, а лишняя строка его уродует.

Единственно, где делаю, пустую строку, это в методах
Код: plaintext
1.
2.
3.
4.
Метод()
{
 тут че-то делаем
 и тут делаем
}
Но тут сам синтаксис каше не разрешает делать вот так
Код: plaintext
1.
2.
3.
Метод()
{тут че-то делаем
 и тут делаем
}

а так
Код: plaintext
1.
2.
3.
Метод()
{ тут че-то делаем
 и тут делаем
}
некрасиво.

Кстати, всегда стараюсь прижимает "нулевой уровень" блоков к левому краю, но это из-за "нищенской" борьбы за место на мониторе.
а это
Код: plaintext
1.
2.
3.
    Метод()
    {   тут че-то делаем
         и тут делаем
    }
раздражает свои транжирством.

А про скобки у меня для себя правило: скобка открытая с новой строки должна закрыться ровно под собой же. Скобка, открытая в середине строки - должна закрыться в этой же строке.
...
Рейтинг: 0 / 0
23.10.2010, 16:36
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36915983
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
еще вот так бывает
Код: plaintext
1.
2.
3.
4.
    if че-то там много чего 
    {
        тут че-то делаем
        и тут делаем
    }
в принципе для меня читаемо, но жадность не позволяет делать также
...
Рейтинг: 0 / 0
23.10.2010, 16:40
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36916010
ser_shu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ser_shu
Гость
Я и говорю, что много раз участвовал в таких обсуждениях с опытными программистами и все находили аргументы экономичности, красоты, удобства, разумности, естественности...
По правде сказать, я со всеми доводами был согласен (как по моему и остальные). Просто остановиться надо на каком то одном стиле.
Когда работает команда и в одном классе методы написаны разными стилями оформления кода, то это точно лишний источник сомнений и потери смысла.
В своем стандарте используем 1 вариант, как в примерах Интерсистемз.
Хотя во время обсуждений стиля расклад почти всегда был 50 на 50.
Но после принятия стандарта все пишут одинаково без каких либо обид или возражений.
...
Рейтинг: 0 / 0
23.10.2010, 17:19
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36916015
ser_shu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ser_shu
Гость
Блок А.Н.А про скобки у меня для себя правило: скобка открытая с новой строки должна закрыться ровно под собой же. Скобка, открытая в середине строки - должна закрыться в этой же строке.
В Каше закрывающая фигурная скобка практически всегда закрывает команду, а не блок, поэтому закрывающая скобка ровно под командой, которую она закрыла, - тоже разумное и удобное правило.
...
Рейтинг: 0 / 0
23.10.2010, 17:38
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36916035
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Блок А.Н.
Код: plaintext
1.
2.
3.
if че-то там много чего 
   {тут че-то делаем
    и тут делаем
   }
А че это некрасиво?
Ну мой вариант ведь тебе тоже не нравится... Т.е. это чисто дело вкуса...
...
Рейтинг: 0 / 0
23.10.2010, 18:37
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36917491
Ymka2007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ymka2007
Гость
чтоб увидеть активные скобки нужно нажать Ctrl-B помоему, или прописать это в настройках студии
кстати очень удобная вещь
...
Рейтинг: 0 / 0
25.10.2010, 11:28
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36917503
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Ymka2007 , если сразу ставить обе скобки, а потом что-то писать внутри... Не допускать "сложных" конструкций... То проблема вообще отпадает.
...
Рейтинг: 0 / 0
25.10.2010, 11:31
| Ответить | Цитировать | Написать  
Соглашения о стандартах кодирования
    #36917537
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Ymka2007чтоб увидеть активные скобки нужно ... прописать это в настройках студии

Так только и спасаюсь от тех, кто не по-моему скобки ставит
...
Рейтинг: 0 / 0
25.10.2010, 11:41
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Соглашения о стандартах кодирования
    #38626787
doublefint
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
doublefint
Участник
Интерсистемс в своем коде всегда следует соглашению о p и t префиксах для имен переменных ( p ublic и priva t e?).
Код: vbnet
1.
2.
3.
4.
5.
6.
Method MQSeriesSendReply(pRequest As Demo.Loan.Msg.SendReply, Output pResponse As Ens.Response) As %Status
{
	$$$TRACE("write to mqseries")
	Set tSC=..Adapter.SendMessage(pRequest.Text)
	Quit tSC
}


Имхо, использование венгерской нотации обычно вызвано неудобством среды разработки. С другой стороны в Студии есть возможность разделить эти переменные расцветкой: Инструменты - Параметры - Редактор - Цвета - Cache Object Script - выбрать элементы Parameter или Local variable (private) и назначить цвет
...
Рейтинг: 0 / 0
26.04.2014, 22:43
| Ответить | Цитировать | Написать  
21 сообщений из 21, страница 1 из 1
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Соглашения о стандартах кодирования
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=39&fpage=21&tid=1556906]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 25ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 62ms
get tp. blocked users:
 2ms
others: 268ms
total:  403ms
созд. / загр.: 403ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]