Здравствуйте, alexey_sz, Вы писали:
_>Собственно немного флеймовая тема, но тем не менее. Есть два диаметральных подхода к комментариям _>1) Комментируем все, что можно _>2) Пишем код так, чтобы комментарии были не нужны . Ну или самый необходимый минимум _>Есть ли у вас требования на работе к комментариям, и если есть то какие ?
Пишу шапку к файлу, классу/структуре/определению типа, методу/функции, макросам (если назначение неочевидно), эти комментарии в стиле doxygen, в коде — неочевидные места.
Здравствуйте, LaptevVV, Вы писали:
LVV> LVV>> Вот сейчас для одной научной лаборатории делаю несколько прог на С++. LVV> LVV>> Проги небольшие (менее 100 строк), поэтому с классами не заморачиваюсь.
LVV> AN>Тогда это тогда не С++, а С и классы не заморочка
LVV> Только я STL использую. LVV> Векторы, деки, списки и стандартные алгоритмы. Ну так как мы в "войнах" можно и продолжить
Но от этого Ваш код не стал ОО.
Мне как то пришлось "очеловечивать" подобные "С++" исходники написанные одним математиком. Поэтому могу точно сказать, что классы несколько упрощают понимание программы. Правда у него длина функции измерялась в метрах.
Здравствуйте, AlexNek, Вы писали:
LVV>> LVV>> Вот сейчас для одной научной лаборатории делаю несколько прог на С++. LVV>> LVV>> Проги небольшие (менее 100 строк), поэтому с классами не заморачиваюсь. LVV>> AN>Тогда это тогда не С++, а С и классы не заморочка LVV>> Только я STL использую. LVV>> Векторы, деки, списки и стандартные алгоритмы. AN>Ну так как мы в "войнах" можно и продолжить AN>Но от этого Ваш код не стал ОО.
Естественно... AN>Мне как то пришлось "очеловечивать" подобные "С++" исходники написанные одним математиком. Поэтому могу точно сказать, что классы несколько упрощают понимание программы. Правда у него длина функции измерялась в метрах.
Ну, он, наверное, STL не использовал. Если б мне пришлось стандартные контейнеры и алгоритмы писать самому — тоже получились бы метры...
В данном случае можно завернуть в класс все операции с решеткой узлов.
Но просто не вижу смысла это делать.
Если при решении последующих задач текст будет разрастаться -я, конечно, предприму шаги подобного рода.
И Меркурий уже установил — на случай как раз разбухания задачи...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Не, не люблю писать длинно... LVV>Ваши предположения — беспочвенны. С самого начала было npos. Комментарий — себе, просто напоминание. LVV>Его и не требуется сопровождать. Работа конкретная и разовая. Заказчика — устраивает достигнутый результат. LVV>Меня в ДАННОМ СЛУЧАЕ устраивает мой стиль, в котором разбираться только мне.
Научник? На одном заводе по сдельному договору писал программу, воплощала результаты какого-то исследования, научники в работе сделали реализацию алгоритма (видать тоже в стол работали, как они предполагали), мне предстояло использовать его... По сути дали его как чёрный ящик. Да вот только при определённых условиях он работал некорректно, пришлось лезть разбираться. Наверное не нужно говорить, что писателя мне хотелось убить. Поэтому в любой программе руководствуйся правилами:
1. Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает где вы живёте (Стив Макконнелл)
2. Код пишется один раз, а читается — множество. Пишите его читабельным. (тоже откуда-то взято на заметку).
Потомки тебе спасибо скажут. Тем более уже даже не только в IDE, даже простых редакторах есть автодополнение по тексту и прочие вкусности.
_>1. Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает где вы живёте (Стив Макконнелл) _>2. Код пишется один раз, а читается — множество. Пишите его читабельным. (тоже откуда-то взято на заметку).
Да, ещё третье правило:
3. "Свой" код становится "чужим" через некоторое (часто крайне малое) время.
Здравствуйте, LaptevVV, Вы писали:
LVV> AN>Мне как то пришлось "очеловечивать" подобные "С++" исходники написанные одним математиком. Поэтому могу точно сказать, что классы несколько упрощают понимание программы. Правда у него длина функции измерялась в метрах.
LVV> Ну, он, наверное, STL не использовал. Если б мне пришлось стандартные контейнеры и алгоритмы писать самому — тоже получились бы метры...
А у него не было вообще ничего стандартного только NP-сложная задача LVV> В данном случае можно завернуть в класс все операции с решеткой узлов. LVV> Но просто не вижу смысла это делать.
Попробуйте просто ради интереса LVV> Если при решении последующих задач текст будет разрастаться -я, конечно, предприму шаги подобного рода.
тогда это может быть уже поздно
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, LaptevVV, Вы писали:
LVV>>int nArg; // -- количество параметров командной строки -- A>commandLineArgN или commandLineArgQty, или commandLineArgCount
А если nArg — глобальная переменная, которая используется в большом проекте 1000 раз?
(Прошу не вдаваться в дискуссию о пользе/вреде глоб.переменных!!!)
Или, например,
Здравствуйте, monah_tuk, Вы писали:
_>Здравствуйте, LaptevVV, Вы писали:
LVV>>Не, не люблю писать длинно... LVV>>Ваши предположения — беспочвенны. С самого начала было npos. Комментарий — себе, просто напоминание. LVV>>Его и не требуется сопровождать. Работа конкретная и разовая. Заказчика — устраивает достигнутый результат. LVV>>Меня в ДАННОМ СЛУЧАЕ устраивает мой стиль, в котором разбираться только мне.
_>Научник? На одном заводе по сдельному договору писал программу, воплощала результаты какого-то исследования, научники в работе сделали реализацию алгоритма (видать тоже в стол работали, как они предполагали), мне предстояло использовать его... По сути дали его как чёрный ящик. Да вот только при определённых условиях он работал некорректно, пришлось лезть разбираться.
Это работа по гранту РФФИ.
Я как раз тот, который после научника...
Меня позвали, чтоб я ускорил работу той проги, что они сами там наваяли.
В результате моей работы код стал: короче, понятнее, намного быстрее (это основное, что требовалось) _>Наверное не нужно говорить, что писателя мне хотелось убить. Поэтому в любой программе руководствуйся правилами: _>1. Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает где вы живёте (Стив Макконнелл) _>2. Код пишется один раз, а читается — множество. Пишите его читабельным. (тоже откуда-то взято на заметку).
Те девочки, которые писали до меня, в моем коде прекрасног разбираются. Тем более, что все имена переменных я оставил по их просьбе прежними... _>Потомки тебе спасибо скажут. Тем более уже даже не только в IDE, даже простых редакторах есть автодополнение по тексту и прочие вкусности.
Не... Мне требуется один и тот же код пускать в Code::Blocks и Студии. И получать одинаковые результаты.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
AN>могу точно сказать, что классы несколько упрощают понимание программы
это все зависит.. это фактически конвертация линейной простыни в развесистый нелинейный граф. И если сущности которые ты выделяешь в отдельные классы/функции имеют четкую, понятную семантику , то это может быть хорошо. Иначе это может быть кошмарней линейной простыни.
Замечу, что многие люди предпочитают линейные ман-страницы и линейные статьи нелинейным info и гипертексту.
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, LaptevVV, Вы писали:
LVV>> AN>Мне как то пришлось "очеловечивать" подобные "С++" исходники написанные одним математиком. Поэтому могу точно сказать, что классы несколько упрощают понимание программы. Правда у него длина функции измерялась в метрах.
LVV>> Ну, он, наверное, STL не использовал. Если б мне пришлось стандартные контейнеры и алгоритмы писать самому — тоже получились бы метры... AN>А у него не было вообще ничего стандартного только NP-сложная задача LVV>> В данном случае можно завернуть в класс все операции с решеткой узлов. LVV>> Но просто не вижу смысла это делать. AN>Попробуйте просто ради интереса LVV>> Если при решении последующих задач текст будет разрастаться -я, конечно, предприму шаги подобного рода. AN>тогда это может быть уже поздно
Никогда не поздно. На полное переписывание хватает одного дня — такого размера текст. И я его стараюсь в таком объеме поддерживать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Я как раз тот, который после научника... LVV>Меня позвали, чтоб я ускорил работу той проги, что они сами там наваяли. LVV>В результате моей работы код стал: короче, _понятнее_, намного быстрее (это основное, что требовалось)
особенно понятнее
_>>Наверное не нужно говорить, что писателя мне хотелось убить. Поэтому в любой программе руководствуйся правилами: _>>1. Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает где вы живёте (Стив Макконнелл) _>>2. Код пишется один раз, а читается — множество. Пишите его читабельным. (тоже откуда-то взято на заметку). LVV>Те девочки, которые писали до меня, в моем коде прекрасног разбираются. Тем более, что все имена переменных я оставил по их просьбе прежними...
Неверно. Девушек переехал каток, тебя переехал каток, код передали другому человеку. Правила простые, легче им следовать всегда и улучшать свою карму, когда твой код, волей судеб достанется другому человеку, и он скажет спасибо.
Вообще, мне нравится как обстоит дело с морским узлом: правильно завязанный узел — красивый. Неправильно завязанный выдержит меньшую нагрузку или вообще развяжется при минимальной оной. Было бы прекрасно, если бы некрасивые программы не запускались бы.
_>>Потомки тебе спасибо скажут. Тем более уже даже не только в IDE, даже простых редакторах есть автодополнение по тексту и прочие вкусности. LVV>Не... Мне требуется один и тот же код пускать в Code::Blocks и Студии. И получать одинаковые результаты.
эээ, и там и там автодополнение есть, какая разница в чём код писать? я же не про логику, я про стилистику и оформление.
Здравствуйте, monah_tuk, Вы писали:
LVV>>Те девочки, которые писали до меня, в моем коде прекрасног разбираются. Тем более, что все имена переменных я оставил по их просьбе прежними... _>Неверно. Девушек переехал каток, тебя переехал каток, код передали другому человеку.
Зачем настраиваться на проблемы — они и без наших усилий нас найдут... _>Правила простые, легче им следовать всегда и улучшать свою карму, когда твой код, волей судеб достанется другому человеку, и он скажет спасибо.
У нас в провинции все друг-друга знают, поэтому с улицы человека не возьмутт, а остальных мы всех знаем... _>Вообще, мне нравится как обстоит дело с морским узлом: правильно завязанный узел — красивый. Неправильно завязанный выдержит меньшую нагрузку или вообще развяжется при минимальной оной. Было бы прекрасно, если бы некрасивые программы не запускались бы. _>>>Потомки тебе спасибо скажут. Тем более уже даже не только в IDE, даже простых редакторах есть автодополнение по тексту и прочие вкусности. LVV>>Не... Мне требуется один и тот же код пускать в Code::Blocks и Студии. И получать одинаковые результаты. _>эээ, и там и там автодополнение есть, какая разница в чём код писать? я же не про логику, я про стилистику и оформление.
Мне подсказки в Студии — мешают. Я и так знаю, что хочу набрать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, alexey_sz, Вы писали:
_>2) Пишем код так, чтобы комментарии были не нужны . Ну или самый необходимый минимум _>Есть ли у вас требования на работе к комментариям, и если есть то какие ?
когда был наёмным работником иногда заставляли комментировать те или иные участки кода, сейчас комментарии никогда не делаю.
Здравствуйте, LaptevVV, Вы писали:
LVV>Мне подсказки в Студии — мешают. Я и так знаю, что хочу набрать.
Странно, отчего тогда народ еще за плагины которые больше подсказок делает платит?
Кстати с ними длинные имена набирать не проблема
Здравствуйте, LaptevVV, Вы писали:
LVV> LVV>> В данном случае можно завернуть в класс все операции с решеткой узлов. LVV> LVV>> Но просто не вижу смысла это делать.
LVV> AN>Попробуйте просто ради интереса
LVV> LVV>> Если при решении последующих задач текст будет разрастаться -я, конечно, предприму шаги подобного рода.
LVV> AN>тогда это может быть уже поздно
LVV> Никогда не поздно. На полное переписывание хватает одного дня — такого размера текст. И я его стараюсь в таком объеме поддерживать.
Это просто два разных "концепта" и думается в них совершенно по другому.
Ну типа если мне надо в "С" изменить "поведение" функции, я думаю где бы мне вставить if, а если в "плюсах", то какую функцию перекрыть. То есть развитие кода идет просто по другому пути и "переписывая" его позже это будет тот же код, но завернутый в классы. Тогда конечно нет в этом смысла.
Здравствуйте, dilmah, Вы писали:
d> AN>могу точно сказать, что классы несколько упрощают понимание программы
d> это все зависит.. это фактически конвертация линейной простыни в развесистый нелинейный граф. И если сущности которые ты выделяешь в отдельные классы/функции имеют четкую, понятную семантику , то это может быть хорошо. Иначе это может быть кошмарней линейной простыни.
Ну я исходил из того что все сделано правильно. Испортить можно все что угодно.
Кроме того, вы упустили одну вещь, что я получаю "обзор" графа, ну типа диаграммы классов.
d> Замечу, что многие люди предпочитают линейные ман-страницы и линейные статьи нелинейным info и гипертексту.
Ну книгу я тоже больше люблю в пдф читать
Мне вот только интересно, как в "С" по заголовкам отделить private и public функции.
Здравствуйте, Чили, Вы писали:
Ч>А если nArg — глобальная переменная, которая используется в большом проекте 1000 раз?
то от нее надо избавиться
Ч>Или, например,
не проще использовать nArg !!!
не проще и не лучше.
надо вынести этот код в отдельную функцию (или несколько фукций), и передавать туда commandLineArgCount как аргумент.
Здравствуйте, monah_tuk, Вы писали:
_>1. Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает где вы живёте (Стив Макконнелл) _>2. Код пишется один раз, а читается — множество. Пишите его читабельным. (тоже откуда-то взято на заметку).
У этого есть обратная сторона: чем понятнее выглядит ваш код, тем больше найдется желающих поковырять его по своему усмотрению, а потом объяснить вам, что если код в результате сломался — то это ваша бага, которую вы должны немедленно починить, потому что из-за вас вся работа стоит
Здравствуйте, alexey_sz, Вы писали:
_>Собственно немного флеймовая тема, но тем не менее. Есть два диаметральных подхода к комментариям _>1) Комментируем все, что можно _>2) Пишем код так, чтобы комментарии были не нужны . Ну или самый необходимый минимум _>Есть ли у вас требования на работе к комментариям, и если есть то какие ?
Хочешь устроить драку среди коллег — затей спор на тему "как лучше комментировать" и "как правильно ставить скобки".
Результат хорошо виден по ответам
А ответ-то простой: РАЗУМНО.
и классы не заморочка 
