OSDev http://osdev.su/ |
|
Правильные имена идентификаторам http://osdev.su/viewtopic.php?f=18&t=739 |
Страница 1 из 2 |
Автор: | JSON [ 25 апр 2013, 10:50 ] |
Заголовок сообщения: | Правильные имена идентификаторам |
Под идентификатором имеется ввиду имена меток, переменных, констант, процедур, классов, функций, файлов. Вопрос больше "А как у вас?!". Например: правильно и лаконично ли имя константы для индекса колонки иконок в таблице пакетов!? const int PACKAGES_TABLE_ICON_COLUMN_INDEX = 0; Всегда путался между вариантами названий: "void* packagesTable", "void* packageTable", "void* tablePackages", "void* tablePackage", "void* tableOfPackages" Лично меня это волнует из-за времени, которое я трачу на это. Также волнует из-за хаоса в именах, когда сбиваешься. У меня выработан стиль написания текстов программ. Я ему следую и это дает прирост производительности. Ну а тут всегда заклинивает. Как нужно осмыслять, из чего исходить, какими правилами пользоваться? Как у вас? |
Автор: | Yoda [ 25 апр 2013, 11:43 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
Есть разные стили именования. Наиболее принятые следующие: Венгерская нотация - szMyString. Этот стиль подразумевает префикс к каждому идентификатору, обозначающий его тип. Например, sz означает "строка, оканчивающаяся нулём. Эта нотация была принята в качестве внутреннего стандарта Майкрософт ещё с древних ДОСовских времён. Разделение подчёркиванием (snake_case) - my_string. Широко принят в среде программистов С. Два варианта CamelCase - lowerCamelCase (myString) и UpperCamelCase (MyString). Этот стиль стал популярным с распространением Java. Я абсолютно разочаровался в венгерской нотации, особенно в крупных проектах со множеством зависимостей. Она была ещё приемлема при работе с С, но вырождается с использованием ООП (C++, C#, Java...). Причины следующие. 1. Префикс напрямую противоречит изоляции интерфейса от реализации. Т.е. он накладывает ограничения на внутренее устройство переменной и даже может вводить в заблуждение. 2. Затрудняет чтение, особенно с распространением производных типов. Очень трудно продираться сквозь дебри составных префиксов, типа lpcszCmdLine. 3. Он фиксирует внутреннее представление переменной. Если по какой-то причине возникла необходимость смены внутреннего представления, то я вынужден по всему проекту заменять название переменной с новым префиксом, даже если смысл использования не изменился. Правда есть и плюсы. Не нужно искать объявление переменной, чтобы узнать её тип. Почему в моём случае минусы перевешивают плюс? Я считаю, что использование большого кол-ва глобальных переменных сама по себе порочная практика, приводящая к массе проблем и иногда делающая невозможной многопоточную работу. Также неправильно делать большое количество публичных переменных класса. В условиях же ограниченного и локального использования переменных польза становится незначительной. Раньше стиль с подчеркиванием часто использовался по той причине, что линкеры часто линковали регистро-независимо. Да и некоторые языки были регистро-независимыми. Сейчас регистровая независимость вырождается. Я остановился на смешанном стиле CamelCase. С большой буквы именую типы, с маленькой - переменные. |
Автор: | SII [ 25 апр 2013, 12:51 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
В Аде принято всегда разделять подчёркиваниями, а каждое слово, входящее в состав идентификатора, писать с большой буквы. Я придерживаюсь этого правила во всех программах на любых языках, но с некоторыми вариациями. Так, если в состав идентификатора входит предлог, я его пишу маленькими буквами (например, Integer_to_Hex). Если делаю что-то в Дельфях, то, естественно, вынужден следовать принятым в тамошней либе стандартам. Ну и т.д. P.S. А венгерская нотация мне никогда не нравилась... |
Автор: | iz56 [ 25 апр 2013, 13:59 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
Код: MyVar dd 0x0ff Главное, чтоб было как-то осмысленно - по возможности (в старом коде разные имена встречаются).msgErrorRead db 'text',0 msgOK db 'text',0 Copy_to_Buf: Локальные в циклах - те которые не несут смысла - вообще l1 l2 и всё такое. Глобальные переменные - это зло - но как бороться - не понятно. Правильно может для доступа к ним использовать код . |
Автор: | pavia [ 27 апр 2013, 10:48 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
Вначале пишу объект потом метод. Str.Write Если использую функциональный язык то. StrWrite ListCreate BlobsInit если можно сделать перезагрузку, то Write. А вообще в книжке совершенный код написано так если язык что-то не позволяет то надо взять или сделать инструмент, транслятор, препроцессор который добавит нужный функционал. Там доётся много советов. По поводу концепции скрытия согласен. Вот только в ООП она неработает. |
Автор: | pavia [ 27 апр 2013, 11:09 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
Цитата: Глобальные переменные - это зло - но как бороться - не понятно. Правильно может для доступа к ним использовать код . Это небольшое зло. И бороться очень легко, в правильном ассемблере есть служебные команды или макросы для создания функций и локальных переменных и параметров. Пример от фирмы Borland. Код: ; Insert standard procedure ; Insert(S,D,I) = Copy(D,1,I-1) + S + Copy(D,I,255) SInsert: ARG SourceP,DWORD,1 ARG DestP,DWORD,1 ARG DestLen,WORD,1 ARG Index,WORD,1 LOC Temp1,BYTE,256 LOC Temp2,BYTE,256 ENTRY FAR CMP Index,1 JGE @@1 MOV Index,1 @@1: LEA DI,Temp1 PUSH SS PUSH DI LES DI,DestP PUSH ES PUSH DI MOV AX,1 PUSH AX MOV AX,Index DEC AX PUSH AX PUSH CS CALL SCopy LES DI,SourceP PUSH ES PUSH DI PUSH CS CALL SConcat LEA DI,Temp2 PUSH SS PUSH DI LES DI,DestP PUSH ES PUSH DI PUSH Index MOV AX,255 PUSH AX PUSH CS CALL SCopy PUSH CS CALL SConcat LES DI,DestP PUSH ES PUSH DI PUSH DestLen PUSH CS CALL SStore EXIT Макросы для старого компилятора в новом уже есть служебные слова, в справке описано. Код: ; ******************************************************* ; * * ; * MACROS * ; * * ; ******************************************************* LOCALS @@ ; Public variable definition macro VAR MACRO Symbol,SType,Count PUBLIC Symbol Symbol LABEL SType IF Count DB SType * Count DUP(?) ENDIF ENDM ; Parameter definition macro ARG MACRO Symbol,SType,Count LOCAL Offset @AP = @AP + SType * Count Offset = @AP Symbol EQU (SType PTR [BP+@AF-Offset]) ENDM @AP = 0 @AF = 0 ; Local variables definition macro LOC MACRO Symbol,SType,Count LOCAL Offset @LP = @LP + SType * Count Offset = @LP Symbol EQU (SType PTR [BP+@LF-Offset]) ENDM @LP = 0 @LF = 0 ; Stack frame modifiers sfFar EQU 01H ;FAR frame sfMarkBP EQU 02H ;Make saved BP odd sfSaveDS EQU 04H ;Save DS at [BP-2] sfInitDS EQU 08H ;Init DS using SS ; Default stack frame type sfDefault = 0 ; Stack frame types IF WindowsVersion WINFAR EQU sfFar+sfMarkBP+sfSaveDS ELSE WINFAR EQU sfFar ENDIF ; Entry code generation macro ENTRY MACRO FrameType IFB <FrameType> @SF = sfDefault ELSE IFIDNI <FrameType>,<NEAR> @SF = 0 ELSE IFIDNI <FrameType>,<FAR> @SF = sfFar ELSE @SF = FrameType ENDIF ENDIF ENDIF IF @SF AND sfMarkBP INC BP ENDIF PUSH BP MOV BP,SP IF @SF AND sfFar @AF = @AP + 6 ELSE @AF = @AP + 4 ENDIF IF @SF AND sfSaveDS PUSH DS @LF = -2 ELSE @LF = 0 ENDIF IF @LP SUB SP,@LP ENDIF IF @SF AND sfInitDS PUSH DS PUSH SS POP DS ENDIF ENDM ; Exit code generation macro EXIT MACRO ArgSize IF @SF AND sfInitDS POP DS ENDIF IF @LF - @LP MOV SP,BP ENDIF POP BP IF @SF AND sfMarkBP DEC BP ENDIF IFNB <ArgSize> @AP = ArgSize ENDIF IF @SF AND sfFar RETF @AP ELSE RETN @AP ENDIF @AP = 0 @LP = 0 ENDM В современном компиляторе используется уже служебные слова proc endp arg,local, компилятора под рукой нет пример не привожу. |
Автор: | Yoda [ 27 апр 2013, 12:46 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
pavia писал(а): А вообще в книжке Стива Макконнелла "Совершенный код" написано так... Скачал. Поставил в очередь на почитание. pavia писал(а): если язык что-то не позволяет то надо взять или сделать инструмент, транслятор, препроцессор который добавит нужный функционал. Именно так была сделана первая версия языка С++ - в виде транслятора в С (Cfront). Однако, здесь мы всё равно упираемся в задачу разработки компилятора. Ведь не так важно, во что мы переводим исходную программу, в текст на ЯВУ или объектный код. От разработки фронтенда компилятора это не спасает. Поэтому я могу смело переформулировать данное утверждение примерно так: "если язык что-то не позволяет, то надо разработать новый язык, который добавит нужный функционал". pavia писал(а): По поводу концепции скрытия согласен. Вот только в ООП она неработает. Это почему? |
Автор: | iz56 [ 27 апр 2013, 14:17 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
Скрытие - это в принципе и есть локальные переменные (и в фасме это тоже есть). |
Автор: | iz56 [ 27 апр 2013, 16:03 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
Кстати, Совершенный код не осилил. Прочитал где-то 30%. Всё правильно, но скучно как-то. А Криса Касперски читаю сейчас - интересно (скачал все(90%) его труды с сайта какого-то инсайдПро). Подумал, во многих хороших книгах не хватает живости, как всё выверено и правильно - как не человек писал. Люди - они не могут не ошибаться. А когда читаешь некоторые экземпляры сильно падает самооценка и дальше читать неохота - так ,в прочем , и с людьми. |
Автор: | pavia [ 29 апр 2013, 22:56 ] |
Заголовок сообщения: | Re: Правильные имена идентификаторам |
Цитата: По поводу концепции скрытия согласен. Вот только в ООП она неработает. Это почему? имеется в виду что не даёт 100% гарантии. Хотя безусловно это плюс. Сокрытие реализации предназначено для контроля ошибок. Если мы скрываем реализацию и предоставим только публичный интерфейс то мы сможем легко контролировать работу. Мы сможем проверить входные и выходные данные. А когда мы передаём объект по ссылке мы должны проверить весь объект что из-за большого числа полей просто не возможно экспоненциальная зависимость. А во вторых так как у объекта есть ещё методы, то мы не можем гарантировать что у нас данные на какой либо стадии рекурсии будут корректными так как мы не знаем, как эта рекурсия пойдёт. |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |