Рекомендуемые правила оформления кода

[Пепел Феникса]

Но если бы и знал синтаксис(язык), я бы всеравно пошёл смотреть сам класс Cache т.к. мне надо знать что делает каждый его метод. Без этого я не узнаю, что делает код.

ну вообще то это переменная cache, и тут еще видно что вы мало применяли STL
если интересно

std::vector<phL::LexicalScanner::Token> cache;
std::vector<phL::LexicalScanner::Token>::iterator cache_it;

[Utkin]

Позволю не согласится. Вы сидите уже 2 часа над размышлением обьяснения ваших мыслей компьютерным языком. И тут ЭВРИКА вы знаете как это сделать, НО мысли такого плана очень быстро растворяются.

Не позволю. Я думал шапочка телепата есть только у меня Откуда Вам известно как я пишу программы и выражаю мысли компьютерным языком?

[MaTBeu]

Да, вы правы, я даже не пытался, потому что я считаю, что приводить код, вырваный из контекста - это плохой пример.

Навскидку, ваш код разбирает конструкции языка вроде

for(int i = 0; i < 10; i++)

Разбивая их на группы на цифровые и нецифровые лексемы. Максимальная длина конструкции = 8 лексем. Также конструкция не может заканчиваться цифрой. Конструкции разделяются пробелами. После этого формируется специальная запись, которая представляет собой объект класса Конструкция (Statement), и скорее всего используется при генерации кода.

[MaTBeu]

Сообщение от Utkin

Не позволю. Я думал шапочка телепата есть только у меня Откуда Вам известно как я пишу программы и выражаю мысли компьютерным языком?

В том-то и дело, что никому не известно, как вы думаете и что вами двигало в момент принятия того или иного решения.

Банальный пример:

if(param != null)
    param = param + "";

Новый человек на проекте подумает, что это избыточный код и уберет проверку, потому что если параметр пустой то, он тоже приведется к пустой строке. А на самом деле будет строка "null" и результат будет непредсказуемым только потому то человек не знал правила преобразования типов.

2Пепел Феникса

Сообщение от Пепел Феникса

ну вообще то это переменная cache, и тут еще видно что вы мало применяли STL
если интересно

std::vector<phL::LexicalScanner::Token> > cache
std::vector<phL::LexicalScanner::Token> >::iterator cache_it;

Похоже, что вы добавили лишний символ ">" в каждой строке.

[Utkin]

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

ЗЫ. Вам не кажется, что мы все дальше отклоняемся от основной ветви повествования?

[Пепел Феникса]

Похоже, что вы добавили лишний символ ">" в каждой строке.

да вы правы.

[MaTBeu]

Сообщение от Utkin

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

Окей. Рад, что вы подтвердили мое утверждение. Спасибо за пример.

P.S. согласен с Utkin. Что-то мы ушли в оффтоп. Нужно возвращаться к теме (это я себе )

[Человек_Борща]

Сообщение от Utkin

Не позволю. Я думал шапочка телепата есть только у меня Откуда Вам известно как я пишу программы и выражаю мысли компьютерным языком?

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

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

Но в голове много не удержишь, человеку сложно делать что-либо более чем в 3 действия одновременно(Начинает допускать ошибки).

Компьюьерные алгоритмы ввиде человеческой мысли - не возможно держать в одно действие. И Именно по этому вам думается хорошо, когда вы ничем физически и умственно не заняты(кроме ваших мыслей об алгоритме работы). И именно по этому придумали карандаш, стирку, бумагу и блок-схемы.

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

Ну да ладно, это уже теория о том, как продумывать будущий код. Ну её к монахам

[anyx]

Посоны, вы спорите ни о чём. Давайте так

Вопрос: насколько подробно надо комментировать код, так ведь? Давайте подумаем, что такое код. Код - это формальная запись алгоритма. Значит (по идее) она должна соответствовать словесному описанию. Составьте словесное описание, и если в каких-то местах что-то непонятно, прокомментируйте соответствующие места в коде.

В жизни всё не так идеально. Ведь думаем мы так: "Для каждого элемента списка применим функцию foo". Конечно, есть языки, где это выражается языком, очень близким к человеческому (Haskell, Erlang, Scheme, Lisp, Python и другие функциональные языки):

b = map(foo, a)

Но в некоторых языках (C/C++/Delphi) мы теряемся в деталях реализации:

std::vector<int> b;
for (int i = 0; i < a.length(); i++)
    b.push_back(a[i]);

Конечно пример утрированный, все знают, что for (int i = 0; i < a.length(); i++) - это проход по всем элементам массива. Но есть примеры, где без поллитра и не разберёшь, что делает код. Кто работал со строками на Си только с помощью стандартной библиотеки, тот поймёт меня.

Вот такие печальные случаи нуждаются в более подробном комментировании (в зависимости от ситуации, иногда придётся комментировать каждую строку)

[still_alive]

А меня никто не спрашивает. Мне дают и говорят чтобы вчера было сделано. Данный код мой (я еще только учился), но он показателен.

Все равно, зачем комментарии? Покажите документацию к коду. Если она есть, но из нее ничего не понятно, то тогда можно и поговорить о необходимости комментариев. Если же документации нет, то нужно материться и ее писать. А заставить кого-то писать документацию не сложнее чем заставить его писать комментарии.

Зачем его переписывать с нуля? Это очередной Ваш минус. Нормальный человек попытается понять алгоритм - если он верен нужно провести рефакторинг.

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