Здравствуйте, B0FEE664, Вы писали:
BFE>В очередной раз перечитав параграф здесь подумал, чем бы таким заменить подчёркивание в начале имён полей классов...
BFE>
BFE>class Test
BFE>{
BFE> std::string ⓂMyAttribute;
BFE>};
BFE>
BFE>- так не красиво. BFE>Пробовал всякую псевдографику, но её gcc не понимает...
BFE>Поэтому вопрос: может уже есть какая-нибудь выработанная практика новой венгерской нотации?
Ну можно рассмотреть варианты, например:
Начинать имена с подчёркивания и строчной буквы.
Перенести подчёркивание в конец.
Использовать ортодоксальный префикс "m_".
Не использовать вообще никаких префиксов и суффиксов. Писать код так, чтоб имена полей не конфликтовали с именами параметров и локальных переменных.
--
Справедливость выше закона. А человечность выше справедливости.
BFE>Отсутствие префикса/суффикса сильно затрудняет чтение кода, особенно в методах экрана на два.
И очень хорошо, что затрудняет. Ибо за методы экрана на два нужно дисквалифицировать. Методы экрана на два демонстрируют неспособность программиста отделять "что" от "как".
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
r> BFE>Отсутствие префикса/суффикса сильно затрудняет чтение кода, особенно в методах экрана на два.
r> И очень хорошо, что затрудняет. Ибо за методы экрана на два нужно дисквалифицировать. Методы экрана на два демонстрируют неспособность программиста отделять "что" от "как".
А если монитор в портретном режиме? Но так-то о#уительная метрика
Здравствуйте, rudzuk, Вы писали:
r>> И очень хорошо, что затрудняет. Ибо за методы экрана на два нужно дисквалифицировать. Методы экрана на два демонстрируют неспособность программиста отделять "что" от "как".
R>А если монитор в портретном режиме? Но так-то о#уительная метрика
Да не, как метрика — так себе. Если тело функции умещается целиком на экране, само по себе это ещё не гарантия, что она не вызовет затруднений при чтении. На#уеплётать можно и в паре строк. Вот тут
Здравствуйте, rg45, Вы писали:
BFE>>Отсутствие префикса/суффикса сильно затрудняет чтение кода, особенно в методах экрана на два. R>И очень хорошо, что затрудняет. Ибо за методы экрана на два нужно дисквалифицировать. Методы экрана на два демонстрируют неспособность программиста отделять "что" от "как".
Дело в том, что бывает как в анекдоте реальной жизни:
Астронавта Джона Гленна спросили, что он чувствовал, когда готовился к полету в космос?
Он ответил: «В точности то же самое, что почувствовали бы вы, зная, что летите на корабле из двух миллионов деталей, каждую из которых изготовил тот, кто предложил правительству наименьшую цену».
— нет бюджета на идеальный код. С одной стороны нужно убедить работников переписать код, который и так работает. С другой — убедить начальство, что вот этот работающий код надо переписать. Если аргументировать, что читать сложно, то могут начать сомневаться в квалификации... Поэтому вводятся формальные требования, апеллируя к которым можно указать на необходимость переписать код. Да, конечно, есть требование, что каждая функция должна влезать на экран, но если тупо ей следовать, то придётся переписывать всякие инициализации состоящие и сотен строчек кода вида XXX = YYY;...
Короче, хочется спросить у тех, кому не нужен префикс, сколько пуллреквестов (от программистов с опытом работы 2-3 года) в день они читают?
Здравствуйте, B0FEE664, Вы писали:
BFE>Дело в том, что бывает как в анекдоте реальной жизни: BFE>
BFE>Астронавта Джона Гленна спросили, что он чувствовал, когда готовился к полету в космос?
BFE>Он ответил: «В точности то же самое, что почувствовали бы вы, зная, что летите на корабле из двух миллионов деталей, каждую из которых изготовил тот, кто предложил правительству наименьшую цену».
BFE>- нет бюджета на идеальный код. С одной стороны нужно убедить работников переписать код, который и так работает. С другой — убедить начальство, что вот этот работающий код надо переписать. Если аргументировать, что читать сложно, то могут начать сомневаться в квалификации... Поэтому вводятся формальные требования, апеллируя к которым можно указать на необходимость переписать код. Да, конечно, есть требование, что каждая функция должна влезать на экран, но если тупо ей следовать, то придётся переписывать всякие инициализации состоящие и сотен строчек кода вида XXX = YYY;...
Это знакомо.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, B0FEE664, Вы писали:
BFE>В очередной раз перечитав параграф здесь подумал, чем бы таким заменить подчёркивание в начале имён полей классов..
Подчеркивание в начале имен, вроде как, входит в конфликт с именами стандартной библиотеки.
Юникод экзотику, я бы в своей практике, рассматривал в самую последнюю очередь.
Для себя выработал набор правил.
Для приватных функций использую постфиксное подчеркивание.
Для приватных дата мемберов — ортодоксальное m_... без буквы типа (аля венгерской нотации), просто m_name.
Для простых структур, где все мемберы публичные, никого префикса sturct Entity { std::string name; };
Здравствуйте, qaz77, Вы писали:
BFE>>В очередной раз перечитав параграф здесь подумал, чем бы таким заменить подчёркивание в начале имён полей классов.. Q>Подчеркивание в начале имен, вроде как, входит в конфликт с именами стандартной библиотеки.
Это если в глобальном пространстве.
Q>Юникод экзотику, я бы в своей практике, рассматривал в самую последнюю очередь.
Эта экзотика уже С++:
Лет через 5 школьники так и будут писать на C++. В священных войнах даже тема была про программы на русском языке...
Q>Для приватных дата мемберов — ортодоксальное m_... без буквы типа (аля венгерской нотации), просто m_name.
Ну вот '_' — это ведь тоже псевдографика, просто к ней все привыкли...
Здравствуйте, B0FEE664, Вы писали:
BFE>В очередной раз перечитав параграф здесь подумал, чем бы таким заменить подчёркивание в начале имён полей классов...
BFE>
BFE>class Test
BFE>{
BFE> std::string ⓂMyAttribute;
BFE>};
BFE>
BFE>- так не красиво. BFE>Пробовал всякую псевдографику, но её gcc не понимает...
BFE>Поэтому вопрос: может уже есть какая-нибудь выработанная практика новой венгерской нотации?
Мы не во времена доса и монохромных мониторов живём. Поэтому простой совет — используйте нормальные IDE, и подсвечивайте поля класса, локальные переменные (и, возможно, аргументы) разными цветами.
Конечно если сильно не упарываться в тему поддержки разработчиков с дальтонизмом. Впрочем некоторые IDE позволяют для этого курсив использовать.
Здравствуйте, SaZ, Вы писали:
SaZ>Мы не во времена доса и монохромных мониторов живём. Поэтому простой совет — используйте нормальные IDE, и подсвечивайте поля класса, локальные переменные (и, возможно, аргументы) разными цветами.
Что посоветуете для сравнения двух версий файлов? Сценарий такой: сотрудник подготовил PullRequest, а мне надо проверить вносимые изменения. Есть инструменты, которые показывают построчные изменения в файлах, но вот чтобы они при этом ещё обеспечивали синтаксическую разметку... Есть такое?
Здравствуйте, B0FEE664, Вы писали:
BFE>Есть инструменты, которые показывают построчные изменения в файлах, но вот чтобы они при этом ещё обеспечивали синтаксическую разметку... Есть такое?
Github умеет.