Проверка осмысленности имен переменных для скрипта Google CodeStyle
А не проще ли ревью кода проводить?
Можешь чуть подробнее?
1. Локальные переменные интересуют? Члены классов?
Чисто из интереса - ini файл предполагается обновлять каждый раз когда используется новая переменная, или он энфорсит какой-то ограниченный набор имен переменных? Зачем все это?
2. Осмысленность - как "похоже на human language", или как "вроде не врет"?
const char *s = "hello, world!"; { name: "s", description: "сумма в долларах"} OK?
1. Локальные переменные интересуют? Члены классов?
Чисто из интереса - ini файл предполагается обновлять каждый раз когда используется новая переменная, или он энфорсит какой-то ограниченный набор имен переменных? Зачем все это?
2. Осмысленность - как "похоже на human language", или как "вроде не врет"?
const char *s = "hello, world!"; { name: "s", description: "сумма в долларах"} OK?
Все это ради интереса спортивного.
Попытались на одном из проектов внедрить code style.
Закончилось тем, что формальные требования человек соблюдает, но из-за отсутствия культуры в названиях читать код спустя месяц уже невозможно.
Формат.ini файла взят за образец пока как простой и понятный.
Классы конечно тоже будут интересовать. Тогда тегом можно сделать не FileName, а FileName:ClassName.
"Осмысленность" на первом этапе будет проверяться человеком (когда делают commit в svn/git/mercury).
Формализовать её я не готов пока, но навскидку можно сделать так:
1. Имя переменной должно отвечать правилам CodeStyle.
2. Имя переменной после разбиения на слова должно распадаться на префикс (i_, m_, n_ и т д прилагательные , существительные и стоп-слова (_of_, _for_ и т д). Например, можно использовать какой-нибудь сторонний модерируемый пополняемый словарь.
3. Описание должно быть не пустым.
4. Описание должно быть угадываемым в рамках контекста. Это значит, что если незнакомому с кодом человеку предложить сопоставить имена переменных с описаниями, то он сделает это однозначно и быстро.
5. Какой-нибудь внешний анализатор семантики прикрутить.
Если по пункту 1 или 2 будут более толковые идеи - welcome.
Вот формулировка из первоисточника (требования к именам переменных в документе CodeStyle).
Попытались на одном из проектов внедрить code style.
Закончилось тем, что формальные требования человек соблюдает, но из-за отсутствия культуры в названиях читать код спустя месяц уже невозможно.
Формат.ini файла взят за образец пока как простой и понятный.
Классы конечно тоже будут интересовать. Тогда тегом можно сделать не FileName, а FileName:ClassName.
"Осмысленность" на первом этапе будет проверяться человеком (когда делают commit в svn/git/mercury).
Формализовать её я не готов пока, но навскидку можно сделать так:
1. Имя переменной должно отвечать правилам CodeStyle.
2. Имя переменной после разбиения на слова должно распадаться на префикс (i_, m_, n_ и т д прилагательные , существительные и стоп-слова (_of_, _for_ и т д). Например, можно использовать какой-нибудь сторонний модерируемый пополняемый словарь.
3. Описание должно быть не пустым.
4. Описание должно быть угадываемым в рамках контекста. Это значит, что если незнакомому с кодом человеку предложить сопоставить имена переменных с описаниями, то он сделает это однозначно и быстро.
5. Какой-нибудь внешний анализатор семантики прикрутить.
Если по пункту 1 или 2 будут более толковые идеи - welcome.
Вот формулировка из первоисточника (требования к именам переменных в документе CodeStyle).
In general the actual name of the variable should be descriptive enough to give a good idea of what the variable is used for. In certain cases, more comments are required.P.S. Автору скрипта продублировал на email вышеизложенное, может месяц не пройдет и он что толковое посоветует.
Class Data Members
Each class data member (also called an instance variable or member variable) should have a comment describing what it is used for. If the variable can take sentinel values with special meanings, such as a null pointer or -1, document this. For example:
private:
// Keeps track of the total number of entries in the table.
// Used to ensure we do not go over the limit. -1 means
// that we don't yet know how many entries the table has.
int num_total_entries_;
Global Variables
As with data members, all global variables should have a comment describing what they are and what they are used for. For example:
// The total number of tests cases that we run through in this regression test.
const int kNumTestCases = 6;
Шаг1 (Простой). Хочу разобраться в коде и добавить новое правило: "Любая переменная, используемая в коде должна быть объявлена в .ini файле внутри блока с именем файла. Ключом должно быть имя переменной. Значением - описание".БОЛЬШЕ БОЙЛЕРПЛЕЙТА, НАПРИМЕР!1111ОДИНОДИНОДИН
Закончилось тем, что формальные требования человек соблюдает, но из-за отсутствия культуры в названиях читать код спустя месяц уже невозможно.Да просто надо утвердить Единый стандартизованный перечень разрешенных имен переменных (ЕСПРИП) и выдавать их строго по личному заявлению с приложением фотокарточки заказным письмом каждый первый и третий четверг месяца.
Отличный троллинг.
Много лучше будет вынести функционал в отдельный скрипт и использовать в дополнение к doxygen.
Благодарю.
Да просто надо утвердить Единый стандартизованный перечень разрешенных имен переменных (ЕСПРИП) и выдавать их строго по личному заявлению с приложением фотокарточки заказным письмом каждый первый и третий четверг месяца.Но как минимум ты прав в том, что вышеописанной хрене не место в cpplint.
Много лучше будет вынести функционал в отдельный скрипт и использовать в дополнение к doxygen.
Благодарю.
Отличный троллинг.Где, не подскажешь?
А то я столько раз уже слышал это слово в применении к местам и событиям, где троллинга никогда и не предполагалось, что уж начал сомневаться, что we are all on equal terms.
Попытались на одном из проектов внедрить code style.имхо вы занимаетесь ерундой
Закончилось
у вас в конторе только макаки работают? сколько штук?
если у вас 300 низкоквалифицированных работников, то я могу еще понять ваш порыв, однако и без имен переменных у вас наверняка есть более серьезные проблемы. и эти проблемы решаются (ну я бы так решал) другими средствами, а именно:
1) хорошим coding style. хороший - это значит, что все ясно, есть примеры, а не только формальные ограничения, структурированное изложение
2) общением между членами команды, будь то ревью кода или семинары
3) непрерывное улучшение кода разными членами команды. любой прохожий взял да и почитал \ исправил код, закомитил \ уведомил товарища
4) автоматическая нотификация всех членов команды с возможностью просмотра кода и коммента к комиту. вы не поверите, но те, кто хочет развиваться, будет всасывать полезную инфу из таких коммитов. у нас в конторе рассылаются диффы после каждого коммита всем членам команды
"Любая переменная, используемая в коде должна быть объявлена в .ini файле внутри блока с именем файла. Ключом должно быть имя переменной. Значением - описание"эхеммм...
как контора зовётся?
чисто чтоб знать, где такое практикуется
Задолбал уже ваш глупый оффтоп.
Название конторы раскрывать не буду. Работаю здесь год, разгребаю наследие.
Google CodeStyle практикуется на Google Summer Code.
Мы на досуге натравили данный инструмент на коммерческий проект.
Поймали пару не thread-safe функций и всё заглохло на этом. Вернулись к code review.
Вверху написано, что всему виной мой личный спортивный интерес и желание разобраться в opensource.
Регистр переменных - это не сама цель. Это лишь маленькая техническая подзадачка.
Дальше нужна аналитика: как запретить разработчику называть "красное" "зеленым" и т д?
P.S. На глумление отвечать больше не буду. Есть конструктивные идеи - предлагайте.
Название конторы раскрывать не буду. Работаю здесь год, разгребаю наследие.
Google CodeStyle практикуется на Google Summer Code.
Мы на досуге натравили данный инструмент на коммерческий проект.
Поймали пару не thread-safe функций и всё заглохло на этом. Вернулись к code review.
Вверху написано, что всему виной мой личный спортивный интерес и желание разобраться в opensource.
Регистр переменных - это не сама цель. Это лишь маленькая техническая подзадачка.
Дальше нужна аналитика: как запретить разработчику называть "красное" "зеленым" и т д?
P.S. На глумление отвечать больше не буду. Есть конструктивные идеи - предлагайте.
маленькая подзадачка - "запретить" разработчику путём прописывания всех переменных в файл?!
я не глумлюсь, хотя стоило бы
по-моему это просто дикость и вскоре от твоего желания "запрещать", тем более таким навороченным автоматизированным путём, от тебя люди будут уходить в другие отделы или в другую фирму
а название конторы не помешало бы тем, кто мог бы неприятно удивиться, придя на работу под твоё начальство
я не глумлюсь, хотя стоило бы
по-моему это просто дикость и вскоре от твоего желания "запрещать", тем более таким навороченным автоматизированным путём, от тебя люди будут уходить в другие отделы или в другую фирму
а название конторы не помешало бы тем, кто мог бы неприятно удивиться, придя на работу под твоё начальство
А что ты так перепугался?
Может ты и есть тот самый разработчик, который "зеленое" "красным" в коде называет?
Отчего ты так боишься, что какая-то внешняя утилита построит список используемых в твоем коде переменных? А тебе зададут по нему вопросы?
Добра всем.
P.S. У нас проект пишут аутсорсеры, так что вам не грозит попасть в их число. Расслабьтесь.
Последняя фраза прекрасна. Можно я ее чуть-чуть переформулирую?
P.S. У нас проект пишут те, кто у нас в штате не числится, так что вам не грозит попасть в их число. Расслабьтесь.
какая-то внешняя утилита построит список используемых в твоем коде переменныхкажется, изначально требовалось вносить все свои переменные в ini самому программисту ручками?
если всё совсем автоматически - то извини, я тебя неправильно понял
"перепугался" - логика из серии "а что ты всполошился, что мы слушаем твой телефон? тебе есть что скрывать?"
стайл гайд для аутсорсеров это хорошо, но всё равно требуется ревью, а то понапишут, подстроившись под утилиту...
Оставить комментарий
Yulka-MOl
Хочу добавить валидатор имен переменных в утилиту cpplint.py.Ссылка на проект: Google C++ Style Guide
Шаг1 (Простой). Хочу разобраться в коде и добавить новое правило: "Любая переменная, используемая в коде должна быть объявлена в .ini файле внутри блока с именем файла. Ключом должно быть имя переменной. Значением - описание".
Шаг2 (Сложный). Хочу добавить синтаксический анализатор, который мог бы проверить "осмысленность" описания.
Буду признателен, если кто-то поможет идеями, как правильно реализовать 2й шаг.
Скорее всего буду смотреть наработки, которые люди используют для hook'ов в системах контроля версий типа svn.
P.S. Делаю ради интереса для себя, не для работодателя.