Концепция имен указателей

Всех приветствую!

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

Сначала именовал их как (*p, *p2, *p3, etc..), пробовал также как - (*ptr_str, *ptr_sub, *ptr_start, *ptr_end, etc), потом все же выработал для себя микро концепцию по именованию указателей прибегая к аббревиатуре или акрониму.

Код (Text):

1.        
2.         ps -> указатель на строку
3.         pss -> указатель на начало строки
4.         pse -> указатель на конец строки
5.         psi -> указатель на строку используя индекс
6.         psub -> указатель на подстроку
7.         psubs -> указатель на начало подстроки
8.         psube -> указатель на конец подстроки
9.         prep -> указатель на подстроку замены
10.         pcopy -> указатель на копию результирующей строки
11.         pcopyi -> указатель на копию результирующей строки используя индекс
12.  

И теперь когда я смотрю на имя указателя мне сразу становится понятно о чем идет речь.

Код (C++):

1.  char *erase(char *str, const char *str2, const int start, const int len) {
2.  
3.         char *ps = str;
4.         const char *ps2 = str2, *pss2 = &str2[start], *psi2 = &str2[start + len];
5.        
6.         while(*ps2) {
7.             if(ps2 < pss2 || ps2 >= psi2) {
8.                 *ps++ = *ps2;
9.             }
10.             ps2++;
11.         }
12.        
13.         *ps = '\0';
14.        
15.         return str;
16.     }
17.  

Вы используете какие-то методы по именованию указателей, или вообще переменных, параметров, etc?

 

Ronin Notation

Смотри https://en.wikipedia.org/wiki/Hungarian_notation

 

Я бы начал с того, что переименовал параметр str в dst, а str2 - в src.

 

Я уверен, что эту нотацию ее изобретателю нашептал дьявол, лично. И именно по этой причине она была принята в качестве стандарта в МС, не к ночи будь она помянута.

Имя переменной не должно говорить о ее структуре, оно должно говорить о ее назначении. И за вот эти всякие p, pps, sz, pdw, pspspppss я бы пи3дил арматурой по пальцам.

 

Я тоже использую префиксы у полей структур и классов. Но они достаточно ограничены:

p - одиночный указатель (сокращение от pointer)
v - указатель на начало массива либо коллекция (сокращение от values)
s - некоторая вложенная структура, либо указатель на начало си-строки(сокращение от struct, string)
f - параметр с плавающей точкой (сокращение от float)
n - целочисленный параметр (сокращение от numeric)

Большее число префиксов вводить не вижу особого смысла.

 

schetchik, stroka, chislo... Выдумывают проблемы на пустом месте

 

Можно на ты - ты меня лично знаешь. Правда пока не догадываешься что я, это я )

И я готов отстаивать свою точку зрения, так как это следствие очень многих лет и килотонн кода.

 

Да запросто, первое же, что попалось:

Код (Text):

1.  
2. void MyCopyMemory(TCHAR *buf, TCHAR *pbData, SIZE_T cbData, SIZE_T bufsize)
3. {
4.   CopyMemory(buf, pbData, min(cbData,bufsize));
5. }
6.  

Делаем его хорошим:

Код (Text):

1.  
2. void MyCopyMemory(TCHAR *pbOutputBuffer, SIZE_T cbOutputSize, TCHAR *pbSourceString, SIZE_T cbSourceSize)
3. {
4.   CopyMemory(pbOutputBuffer, pbSourceString, min(cbOutputSize, cbSourceSize));
5. }
6.  

и тут же избавляемся от префиксов:

Код (Text):

1.  
2. void MyCopyMemory(TCHAR *OutputBuffer, SIZE_T OutputSize, TCHAR *SourceString, SIZE_T SourceSize)
3. {
4.   CopyMemory(OutputBuffer, SourceString, min(OutputSize, SourceSize));
5. }
6.  

После чего спрашиваем себя: а что, собственно, стало хуже то? "pbSourceString" несет больше информации, чем "SourceString"? Нет, так как String - это строка, некоторый буфер с последовательностью символов, и это понятно интуитивно и сразу. Зато пропало дублирование этой информации и глаза не спотыкаются на этом "pb", код стал более похож на обычный человеческий язык.
А что изменилось с заменой "cbSourceSize" на "SourceSize"? Тоже, может, стало хуже? И тоже нет.

Ясное дело, что если мы будем как му.. программеры микрософта называть переменные pbData и cbData, то тогда... хотя и префиксы нас тогда тоже не спасут.

Ну и в качестве вишенки - это, наверное, очень приятно глобально заменять в проекте все переменные wWordCount на iWordCount после того, как все же решили сменить ее тип с short на int.

Код (Text):

1.  
2. void MyCopyMemory(TCHAR *buf, TCHAR *pbData, SIZE_T cbData, SIZE_T bufsize)
3. {
4.     CopyMemory(buf, pbData, min(cbData,bufsize));
5. }
6.  
7. void main()
8. {
9.     TCHAR buf[BUFFER_SIZE] = TEXT("This is the destination");
10.     TCHAR pbData[BUFFER_SIZE] = TEXT("This is the source");
11.  
12.     MyCopyMemory(buf, pbData, COPY_SIZE*sizeof(TCHAR), BUFFER_SIZE*sizeof(TCHAR));
13.  
14.     _tprintf(TEXT("Destination buffer contents: %s\n"), buf);
15. }
16.  

 

А еще можно написать fckmSourceString, тогда тоже будет ясно, что она юникодная. Главное, это научить программистов и сочуствующих правильно дешифровать абревиатуры. Все помнят как легко читаются регэкспы?

Когда действительно важно знать, мультибайт или юникод строка, то это надо вносить в название, например SourceUnicodeString. Если же в название характеристику вносить не надо, значит не так уж и важно.

Я предлагаю обсуждать "в глобальном", так как частности всякие бывают.

 

Завязывал бы ты уже в досе сидеть. 2к17 на дворе - наводишь мышь на имя переменной и умный редактор показывает в тултипе ее тип

 

dst как расшифровывается? В целом интересный вариант.

v слишком многозначно, тогда уж ps или pb.

А потом какой-нибудь англоговорящий смотрит в ваш код и не поймет контекст о чем речь, если только вы не пишите для себя.

ol., вы из мира джаваскрипт пришли?

Кто вам сказал что в досе сижу?

 

dst == destination

 

TermoSINteZ, нет никакого питона, есть пайтон, с ударением на о.

 

О, да. Другое дело pss - сразу всем понятно назначение переменной просто из названия.

 

rmn, в самом начале файла оставить описание концепции имен указателей на en, как это у меня сделано в первом посту.