Comments 10
если вы будете использовать чужие библиотеки — смысл есть подстраиваться… а если ваш язык получится хорошим — то будут подстраиваться под вас
Ну :) Мы уже решили, что примем это решение за них :). У нас и так семантика у языка весьма свободная, если ещё и лексика такой будет, то выйдет полная каша. А нечувствительность к регистру, вроде, как раз больше свободы даёт. По крайней мере, может сдружить любителейГорбатыхЖивотных и любителейробапайка :)
Проблемы со слишком короткими идентификаторами начинаются тогда, когда их начнёт вводить пользователь.
Да, насчёт printf() не поспоришь, а вот в примере с 'c' — запросто. Если понадобится ввести ещё одну переменную, которая является символом? Например, мы читаем побайтно UTF-8 и преобразовываем в Unicode scalar value. В результате получаем две переменные: исходную char c и новую UChar32 unicode_char. Предложите её назвать uc? Ага, а потом «случайно» ошибиться в математике типа:
И разбираться, почему ж это вдруг трёхбайтные символы неправильно декодируются.
Другой пример? Элементарно. Предложите имена «в своём стиле» для функций:
char *u_strToUTF8 — UTF-8 -> внутреннее представление. При нахождении некорректных последовательностей UTF-8 возвращается ошибка.
UChar *u_strFromUTF8 — внутреннее представление -> UTF-8. При нахождении некорректных последовательностей возвращается ошибка.
char *u_strToUTF8WithSub — внутреннее представление -> UTF-8. Вместо некорректных последовательностей вставляется указанный пользователем символ.
UChar *u_strFromUTF8WithSub — UTF-8 -> внутреннее представление. Вместо некорректных последовательностей вставляется указанный пользователем символ.
UChar *u_strFromUTF8Lenient — внутреннее представление -> UTF-8. Некорректных последовательностей исходная строка содержать не должна.
И ещё столько же функций для UTF-32.
Ещё пример? Вы пишете библиотеку длинной арифметики. Типы данных: целое фиксированной длины, целое неограниченной длины, рациональное число из целых неограниченной длины, комплексное число из рациональных, число с плавающей точкой ограниченной разрядности, комплексное число из чисел с плавающей точкой. Используя стиль именования а-ля lpfnWndProc, предложите, например, как будет называться функция умножения рационального на комплексное и функция сложения комплексного из рациональных и комплексного из чисел с плавающей точкой. После этого я предлагаю вам оценить, с какой вероятность программист перепутает что-либо при использовании такой библиотеки или допустит банальную опечатку. И читабельность тоже хорошо бы оценить.
Да, насчёт printf() не поспоришь, а вот в примере с 'c' — запросто. Если понадобится ввести ещё одну переменную, которая является символом? Например, мы читаем побайтно UTF-8 и преобразовываем в Unicode scalar value. В результате получаем две переменные: исходную char c и новую UChar32 unicode_char. Предложите её назвать uc? Ага, а потом «случайно» ошибиться в математике типа:
uc = ((c1 & 0x0F) << 12) |
((c2 & 0x3F) << 6) |
(c3 & 0x3F);И разбираться, почему ж это вдруг трёхбайтные символы неправильно декодируются.
Другой пример? Элементарно. Предложите имена «в своём стиле» для функций:
char *u_strToUTF8 — UTF-8 -> внутреннее представление. При нахождении некорректных последовательностей UTF-8 возвращается ошибка.
UChar *u_strFromUTF8 — внутреннее представление -> UTF-8. При нахождении некорректных последовательностей возвращается ошибка.
char *u_strToUTF8WithSub — внутреннее представление -> UTF-8. Вместо некорректных последовательностей вставляется указанный пользователем символ.
UChar *u_strFromUTF8WithSub — UTF-8 -> внутреннее представление. Вместо некорректных последовательностей вставляется указанный пользователем символ.
UChar *u_strFromUTF8Lenient — внутреннее представление -> UTF-8. Некорректных последовательностей исходная строка содержать не должна.
И ещё столько же функций для UTF-32.
Ещё пример? Вы пишете библиотеку длинной арифметики. Типы данных: целое фиксированной длины, целое неограниченной длины, рациональное число из целых неограниченной длины, комплексное число из рациональных, число с плавающей точкой ограниченной разрядности, комплексное число из чисел с плавающей точкой. Используя стиль именования а-ля lpfnWndProc, предложите, например, как будет называться функция умножения рационального на комплексное и функция сложения комплексного из рациональных и комплексного из чисел с плавающей точкой. После этого я предлагаю вам оценить, с какой вероятность программист перепутает что-либо при использовании такой библиотеки или допустит банальную опечатку. И читабельность тоже хорошо бы оценить.
IMHO, для вашего примера, как раз что-то вроде:
strfromutf8withsub будет неплохо читаться, потому что в нём есть две цепляющие взгляд цепочки: str и utf8. А вот перепады большие-маленькие буквы мне немного поскребли мозг. Особенно сочетения UTF8W, на автомате не срабатывает опознование того, где оканчивается UTF8… Может тут, гораздо лучше использовать подчёркивание ещё одно?
А с библиотекой у нас проблем нет. Потому что такой код предполагается заворачивать в определения операторов, ну и плюс полиморфизм. Но вообще, математики, программирующие на фортране или Си с такой проблемой сталкиваются, и они всё-равно предпочитают здесь односимвольные обозначения, вроде
Возможность же опечататься действительно есть…
strfromutf8withsub будет неплохо читаться, потому что в нём есть две цепляющие взгляд цепочки: str и utf8. А вот перепады большие-маленькие буквы мне немного поскребли мозг. Особенно сочетения UTF8W, на автомате не срабатывает опознование того, где оканчивается UTF8… Может тут, гораздо лучше использовать подчёркивание ещё одно?
А с библиотекой у нас проблем нет. Потому что такой код предполагается заворачивать в определения операторов, ну и плюс полиморфизм. Но вообще, математики, программирующие на фортране или Си с такой проблемой сталкиваются, и они всё-равно предпочитают здесь односимвольные обозначения, вроде
add_cq для 'сложить комплексное и рациональное', вместо comlex_plus_rational, потому что формулы сложные, и в итоге читать очень сложно текст становится с длинными обозначениями операций. Это опыт, я с математиками работаю, они именно так пишут.Возможность же опечататься действительно есть…
А если дать возможность при инициализации переменной задавать к ней метаданные, в том числе описание. И сделать в инструменте по работе с кодом функцию быстрого просмотра этих данных, например по всплывающей подсказке при наведении на переменную в коде.
Моё мнение по этому поводу очень простое: printf, stdout и проие стандарнтые идентификаторы могут и не выражать никакого смысла, это слихвой компенисруется man-страницами (man printf; man stdout;...); если же вы не планируете писать man-страницу для вашей функции printd, то лушче назовите её print_struct_dump или даже print_struct_xxx_dump_to_stderr. Исключение составляют случаи, когда идентификатор используется только в пределах 10-20 строк. Тогда его лучше делать в 1-2 буквы, а смысл его можно уточнить в комментарии, если этот смысл не очевиден (sm=0x80 /* active streams mask */).
Sign up to leave a comment.
К вопросу об идентификаторах