WAAAAAAAAAGH!!!!!!1111ONEONE
Пожалуйста, приведите примеры хорошего стиля программирования/оформления сорцев в вашем понимании. Очень хочется сверить с тем, чем нас пичкает препод в институте
-
-
26.05.2005 в 23:081. нормальные названия переменных.. не короткие, но и с понятным смыслом... в-общем что-то среднее между n и UserLastRegisteredName... оно должно читаться, быть понятным и лёгким для запоминания...
2. отступы... текст в каждом новом блоке отступает от предыдущего на n символов.. обычно или n = 4/8 пробелов, или n = табуляции...
оформление имхо всё... больше ничего особенного не выделил )
хороший стиль немного другое... это что-то типа не использовать goto в си и т. п.
-
-
26.05.2005 в 23:09Это понятные интуитивно названия переменных, форматирование функции и циклов, с учетом вложенности.
А чм собственно пичкае тебя препод, что ты засомневался?
-
-
26.05.2005 в 23:16-
-
26.05.2005 в 23:23Все правильно. тех ктоничего не знают заставляют учить что и где расставляя и читая комментарии, форматирование... нормально. Ты хелпы видел? Идентично.
-
-
26.05.2005 в 23:30Отступы - обязательно. Я ещё логические блоки внутри функции отделяю пустой строкой + комментарий - очень не люблю делить функцию на кучу мелких, если больше этими мелкими нигде пользоваться не собираюсь (опять-таки, стек дёргать попусту...). Конечно, при условии, что функция не превышает 100 строк - иначе обязательно делить.
Всегда обязательно фигурные скобки (в языках типа C/C++, C#, Java) ставлю на отдельных строках и даже в том случае, если тело цикла занимает всего одну строку - повышает читабельность и помогает избежать ошибок в дальнейшем, если вдруг придётся ещё что-то в цикл добавить.
Естественно, все сложные моменты должны быть откомментированы, крайне желательно - на английском. Простые функции, назначение которых понятно из названия и алгоритм не вызывает вопросов, никогда не комментирую, это отвлекает внимание.
Всё, пожалуй... Есть ещё определённые правила, которых я придерживаюсь при проктировании GUI, но это уже совсем другая история;о)
-
-
26.05.2005 в 23:34-
-
26.05.2005 в 23:46-
-
27.05.2005 в 00:09-
-
27.05.2005 в 00:46-
-
27.05.2005 в 00:52А про работу - у кого был другой препод, те уже написанные мной курсовики сдали
-
-
27.05.2005 в 01:06-
-
27.05.2005 в 01:10-
-
27.05.2005 в 01:13-
-
27.05.2005 в 10:31Всегда обязательно фигурные скобки (в языках типа C/C++, C#, Java) ставлю на отдельных строках
Имхо, ставить открывающую { на каждой строке - толко увелисивать визувальную длину кода (а у меня монитор не резиновый, хочется видеть побольше текста за раз).
А венгерская нотация дял строго типизированных языков типа Java имхо - излишняя. Потому как IDE легко напомнит тип переменной, если забудешь, а компилятор выругается если перепутаешь.
И главное, что прикажешь писать для объектов нестандартных типов?
-
-
27.05.2005 в 10:35-
-
27.05.2005 в 12:05Хотя я иногда переменные пишу типа img_tmp.... Но обычно UserName...
честно говоря меня бесит стиль типа
for(i=0;i>10;i++)
{
t +=i;
}
.... и т.д. и все в однустрочку....
Нравиться так..
for(i=0;i>10;i++){
t +=i;
}
-
-
27.05.2005 в 12:08Ага, согласен. Именно об этом стиле я и говорил.
Разумеется внтури цикла ставлю отступ, 2 пробела. 4/8 для меня слишком много.
-
-
27.05.2005 в 12:10А вообще если использовать EditPlus или UltraEdit то он сам все это продумывает....
-
-
27.05.2005 в 18:39-
-
28.05.2005 в 04:44-
-
28.05.2005 в 04:51pash_ka По поваду IDE ето конечно все здорово но желательно чтоб текст и в обычном notepad смотрелся нормально ситуаций в жизни много.
Vj_o-oy Имхо вас действительно до общего уровня тянут ,а вот то что на первом курсе начали на си нормально работать для меня новость
-
-
28.05.2005 в 10:57Для Java пользуюсь только JBuilder-ом, а PHP - да, приходится. Только я обычно не notepad-ом, а ФАР-ом с Колорером.
И ощутимых проблем от неиспользования венгерской нотации не замечал. Обычно по названию переменной понятно (по смыслу - в чём такое можно хранить). Типа $rowCount или $sportName.
Да и не живут они (переменные) долго. У меня есть может пяток глобальных переменных, которые во всех моих сайтах живут, а остальное стараюсь внутрь функции или объектов загонять.
-
-
01.06.2005 в 03:39Открывающая скобка на отдельной строке визуально выделяет внутренний блок значительно лучше чем просто табуляция.
Венгерская конвенкция особенно полезна при работе в команде. По традиции израильского образования, большинство домашек и практически все курсовые/дипломы/итд выполняются в парах. С тех пор, как я своего напарника приучила к венгерской конвенкции, скорость поиска ошибок в не-своих блоках выросла в несколько раз.
Для нестандартных типов подбираю удобный трёхбуквенный префикс, иногда объясняю все нестандартные префиксы комментарием в начале файла (обычно внутри класса, перед декларацией переменных-членов).
-
-
01.06.2005 в 09:11Понятно. Фенкс за разъяснения.
Хотя первое - про { - всё-таки спорно. А в комманде не работал, поэтому не могу судить.
Тем не менее, хочу обратить внимание всех интересующихся на книгу Брюсса Эккеля "Thinking in Java" и указания по написанию "хорошего" кода (ссылки нету, т.к. можно только скачать. Приложение B, файл TIJ320.htm), которые он там приводит.
В частности, по поводу Венгерской нотации.
Don’t create your own “decorated” private field names. This is usually seen in the form of prepended underscores and characters. Hungarian notation is the worst example of this, where you attach extra characters that indicate data type, use, location, etc., as if you were writing assembly language and the compiler provided no extra assistance at all. These notations are confusing, difficult to read, and unpleasant to enforce and maintain. Let classes and packages do the name scoping for you. If you feel that you must decorate your names to prevent confusion, your code is probably too confusing anyway and should be simplified.
-
-
01.06.2005 в 19:31Если не пользоваться венгерской нотацией - имена получаются слишком длинными или просто очень тяжело подобрать достаточное количество логичных имён. Согласись, что автоматически сгенерированные имена далеки от совершенства... Я вообще не пользуюсь номерами в именах переменных, если только этот номер не связан с назначением переменной.
-
-
01.06.2005 в 20:23Согласен, номера - очень редко нужны, но я не совсем понял к чему это сказанно? Вроде никто их не рекомендовал. Как и "автоматически сгенерированные имена".
Я, например, заменяю такие "автоматические" имена типа "jPanel1" на что-то вроде "logPanel" и мне кажется это вполне удобно, когда речь идёт об элементе интерфейса. (А где ещё эти авто-имена создаются?) Я тут говорю о графическом интерфейсе, потому что здесь действительно тип объекта настолько важен, что лучше видеть его в имени. Но это, кажется, чуть-ли не единственный случай.
Ещё есть такой момент как соответвие имён методов которые читают/пишут свойства JavaBean с именами переменных.
В стандарте прописанны имена методов is*(), get*(), set*() (например isEnabled(), setEnabled(), getContent() ).
И JBuilder, например, генерирует эти методы автоатизированно, если у меня правильно названные переменные.
Для переменной bEnabled я получу методы isBEnabled(), setBEnabled() что отнюдь не то что нужно. Разумеется исправить легко, как и написать их самому. Но зачем?
Кстати, по поводу "{". Есть официальный SUN-овский стандарт в котром как раз рекомендованно { на новую строку не ставить.
-
-
06.06.2005 в 22:44В начале каждого файла желательно помещать следующую информацию:
//----------------------------------------------------------------
// Файл: <название текущего файла>
// Проект: <название проекта>
// Класс: <реализуемый класс/шаблон/интерфейс>
// Описание: <описание файла, его назначение>
// Дата создания: <дата>
// Дата изменения: <дата последнего изменения>
// Автор: <имя автора>
// Контактные данные: <эл. почтовый ящик автора и т.п.>
//
// <список изменений: дата - автор - краткое описание>
//----------------------------------------------------------------
Идентификаторы любого глобального элемента (переменной, константы (не макроса), функции) должны начинаться с заглавной буквы.
Имена классов, шаблонов, структур, перечисляемых типов, свойств, функций и методов должны начинаться с заглавной буквы. Если название состоит из нескольких слов, начало каждого из них так же должно начинаться с большой буквы. Желательно, что бы первая буква имени отражала принадлежность элемента к какому-либо типу. Например:
C - класс (CSomeClass)
T - шаблон (TSomeTemplate)
S - структура (SSomeStructure)
E - перечисляемый тип (ESomeEnumeration)
I - интерфейс (ISomeInterface)
Все буквы макроопределений должны быть заглавными, а отдельные слова разделяться знаком подчеркивания '_'.
Имена защищаемых данных классов и шаблонов должны начинаться с префикса 'm_', после которого должно следовать название, начинающееся с заглавной буквы.
Имена локальных переменных должны начинаться со сточной буквы, а слова должны разделяться знаком подчеркивания '_'. Альтернативный вариант - название переменной начинается с маленькой, все остальные слова - с заглавной.
Для свойств допустимы два варианта: либо описание свойств как локальных переменных, либо как функций. Первый вариант более предпочтителен.
Разделители применяются для облегчения просмотра файлов. Хорошо организованная система оформления позволяет находить требуемые участки гораздо быстрее. Желательно, после разделителя добавлять назначение элемента, описание параметров и т.д.
Описанию классов, шаблонов, структур, перечисляемых типов должна предшествовать строка (как правило, 60/70/80 символов):
//*************************************
Перед конструктором класса, шаблона, структуры:
///////////////////////////////////////
Перед деструктором класса, шаблона, структуры:
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Перед описанием метода класса, шаблона:
//-------------------------------------
Перед глобальной функцией или группой глобальных переменных или констант:
//=====================================
Многие IDE поддерживают использование пользовательских макросов. Например, в Visual Studio удобно сделать макросы, генерирующие соответсвующий тип комментариев по строке объявления функции.
Описание функций желательно делать наподобие:
//-----------------------------------------------------------------------------
//.Описание:
//.Параметры:
//...<список параметров> - <описание>
//.Возвращаемое значение:
//...<возвращаемое значение> - <описание>
//.Исключения:
//...<список генерируемых исключений> - <описание>
//-----------------------------------------------------------------------------
В роли объекта исключения должен выступать класс, наследованный от базового класса, единого для всех типов исключений, имеющихся в проекте. Это позволяет производить обработку, как отдельно взятых групп, так и всей совокупности ошибок работы программы. Соответственно, базовый класс исключения должен поддерживать универсальные средства диагностики причин возникновения ошибки:
1. Получение текстовой строки, описывающей причину возникновения исключения
2. Получение текстовой строки имени класса, сгенерировавшего исключение
3. Организация доступа к объекту или списку объектов, вызвавших исключение
4. Запись отладочной информации в журнал и т.д.
Использование фигурных скобок:
..if(<выражение>)
....<одна строка>;
..if(<начало длинного выражения>
....<окончание длинного выражения>)
..{
....<одна строка>;
..}
..if(<выражение>)
..{
....<строка>;
....<строка>;
..}
Вызов функции с большим количеством параметров:
..func(
....param_1, // описание
....param_2, // описание
....param_n); // описание
Знак указателя/ссылки (звездочка/амперсанд) примыкает к переменной, а не к типу:
int *a;
Использование префиксов, определяющих тип переменной - опционально, постфиксов - желательно:
CCoolButton my_cool_btn, anotherCoolBtn;
Логические блоки кода разделяются пустой строкой (допускается и двухуровневое разделение).
Удобно настроить подстетку кода таким образом, чтобы выделялись ярким цветом безымянные константы (как численные, так и строковые) - они будут постоянно попадаться на глаза и будет лишний повод ввести типизированую константу, макроопределение, загрузку из ресурсов и т.п.
-
-
18.06.2006 в 23:42по поводу сокращений - лично меня это напрягает, требуетца время чтобы врубитца какое сокращение что означает, особенно когда работаешь в большой комманде и у каждого свои сокращения... а если текст приходитца долго листать то это обычно сигнал что надо рефакторингом выделить пару методов, а не сокращать имена переменных)