Здравствуйте, jazzer, Вы писали:
L>>А то есть тут за соседним столом один кадр, который уделяет повышенное внимание отделению знаков == и = пробелами от аргументов. Ни одного не пропустит, но при этом в код постоянно пролезает такой очевидный ужас, что становится страшно. J>судя по твоим словам, ты еще не читал книжку саттера-александреску по поводу стайл гайдов — рекомендую, там как раз одним их первых пунктов идет "не приколупывайтесь к мелочам!" (ну, может, глагол другой немножко )
Не читал. К сожалению, мне ее уже поздно читать
Правда, толку от это очень мало — большинство современных программистов, с кем приходится иметь дело, не то что Александреску не читали, но и о том, кто такой Кнут, имеют очень смутное представление.
Могу попробовать сослаться на Александреску, но, боюсь, получу вопрос класса "а кто это?"
Здравствуйте, landerhigh, Вы писали:
L>Не читал. К сожалению, мне ее уже поздно читать
В смысле, ты уже на плюсах не пишешь?
L>Правда, толку от это очень мало — большинство современных программистов, с кем приходится иметь дело, не то что Александреску не читали, но и о том, кто такой Кнут, имеют очень смутное представление. L>Могу попробовать сослаться на Александреску, но, боюсь, получу вопрос класса "а кто это?"
лучше на Саттера — про него можно ответить, что это секретарь комитета по стандартизации С++ и один из главных в команде мелкософтовского компилятора (насчет второго могу ошибаться, правда).
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, landerhigh, Вы писали:
L>>Не читал. К сожалению, мне ее уже поздно читать J>В смысле, ты уже на плюсах не пишешь?
Нет. Просто что бы я не начинал читать, понимаю, что по всем этим граблям уже ходил-с и с автором категорически согласен
L>>Правда, толку от это очень мало — большинство современных программистов, с кем приходится иметь дело, не то что Александреску не читали, но и о том, кто такой Кнут, имеют очень смутное представление. L>>Могу попробовать сослаться на Александреску, но, боюсь, получу вопрос класса "а кто это?" J>лучше на Саттера — про него можно ответить, что это секретарь комитета по стандартизации С++ и один из главных в команде мелкософтовского компилятора (насчет второго могу ошибаться, правда).
Это опасно. Тут есть народ, который до сих пор при виде шаблонов в обморок падает
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, landerhigh, Вы писали:
L>>>Не читал. К сожалению, мне ее уже поздно читать J>>В смысле, ты уже на плюсах не пишешь? L>Нет. Просто что бы я не начинал читать, понимаю, что по всем этим граблям уже ходил-с и с автором категорически согласен J>>лучше на Саттера — про него можно ответить, что это секретарь комитета по стандартизации С++ и один из главных в команде мелкософтовского компилятора (насчет второго могу ошибаться, правда). L>Это опасно. Тут есть народ, который до сих пор при виде шаблонов в обморок падает
Погоди, похоже, мы о разных книгах говорим.
Я имею в виду их совместную книгу "Стандарт программирования С++" или как-то так, в общем, они не про шаблоны и прочее, а про самые банальные вещи говорят.
Очень полезная книжка для командной работы, вот тебе бы она как раз пригодилась в борьбе с твоим занудным соседом.
Здравствуйте, jazzer, Вы писали:
L>>Это опасно. Тут есть народ, который до сих пор при виде шаблонов в обморок падает J>Погоди, похоже, мы о разных книгах говорим. J>Я имею в виду их совместную книгу "Стандарт программирования С++" или как-то так, в общем, они не про шаблоны и прочее, а про самые банальные вещи говорят. J>Очень полезная книжка для командной работы, вот тебе бы она как раз пригодилась в борьбе с твоим занудным соседом.
Да все о том же. Определенными авторами и их произведениями неокрепших программистов можно напугать до смерти. Вот тут как раз такой случай
Здравствуйте, landerhigh, Вы писали:
L>Да все о том же. Определенными авторами и их произведениями неокрепших программистов можно напугать до смерти. Вот тут как раз такой случай
Самокритично так выразился, респектуха
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, landerhigh, Вы писали:
J>>Я имею в виду их совместную книгу "Стандарт программирования С++" или как-то так, в общем, они не про шаблоны и прочее, а про самые банальные вещи говорят. J>>Очень полезная книжка для командной работы, вот тебе бы она как раз пригодилась в борьбе с твоим занудным соседом. L>Да все о том же. Определенными авторами и их произведениями неокрепших программистов можно напугать до смерти. Вот тут как раз такой случай
Что до правил оформления кода, то вот что о них говорится:
Issues that are really just personal taste and don't affect correctness or readability don't belong in a coding standard. Any professional programmer can easily read and write code that is formatted a little differently than they're used to.
Do use consistent formatting within each source file or even each project, because it's jarring to jump around among several styles in the same piece of code. But don't try to enforce consistent formatting across multiple projects or across a company.
Here are several common issues where the important thing is not to set a rule but just to be consistent with the style already in use within the file you're maintaining:
* Don't specify how much to indent, but do indent to show structure: Use any number of spaces you like to indent, but be consistent within at least each file.
* Don't enforce a specific line length, but do keep line lengths readable: Use any length of line you like, but don't be excessive. Studies show that up to ten-word text widths are optimal for eye tracking.
* Don't overlegislate naming, but do use a consistent naming convention: There are only two must-dos: a) never use "underhanded names," ones that begin with an underscore or that contain a double underscore; and b) always use ONLY_UPPERCASE_NAMES for macros and never think about writing a macro that is a common word or abbreviation (including common template parameters, such as T and U; writing #define T anything is extremely disruptive). Otherwise, do use consistent and meaningful names and follow a file's or module's convention. (If you can't decide on your own naming convention, try this one: Name classes, functions, and enums LikeThis; name variables likeThis; name private member variables likeThis_; and name macros LIKE_THIS.)
* Don't prescribe commenting styles (except where tools extract certain styles into documentation), but do write useful comments: Write code instead of comments where possible (e.g., see Item 16). Don't write comments that repeat the code; they get out of sync. Do write illuminating comments that explain approach and rationale.
Finally, don't try to enforce antiquated rules (see Examples 3 and 4) even if they once appeared in older coding standards.
Из всех рекомендаций по оформлению кода, которые мне приходилось видеть эти, пожалуй, самые лояльные.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Самокритично так выразился, респектуха :) (-)
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, landerhigh, Вы писали:
L>>Да все о том же. Определенными авторами и их произведениями неокрепших программистов можно напугать до смерти. Вот тут как раз такой случай E>Самокритично так выразился, респектуха
Подколол таки, чертяга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, landerhigh, Вы писали:
E>Из всех рекомендаций по оформлению кода, которые мне приходилось видеть эти, пожалуй, самые лояльные.
У меня сложилось впечатление, что после определенного числа проектов и связанных с ними развлечений, любой программист приходит к более-менее такому же набору правил.
Как пример — приходит понимание, что размер табуляции на читаемость не влияет никак, зато код с неоднородным выравниванием читать гораздо сложнее, нежели тот, где выравнивание было сделано в одном стиле. Что наличие или отсутствие пробелов до и после операторв вообще никак не влияет, но строки кода, которые по ширине не влезают на 22" монитор, отбивают не только желание читать этот код, но и вообще иметь с ним (и с его автором) дело. То же самое с оформлением комментариев и прочего (главное, чтобы человек и doxygen поняли).
Просто у тех, кому пришлось знатно покопаться в спагетти-коде, возникает ложное, хотя и оправданное мнение, что для наступления полной нирваны необходимо и достаточно заставить всех подряд расставлять пробелы согласно прейскуранту.
Здравствуйте, landerhigh, Вы писали:
L>Просто у тех, кому пришлось знатно покопаться в спагетти-коде, возникает ложное, хотя и оправданное мнение, что для наступления полной нирваны необходимо и достаточно заставить всех подряд расставлять пробелы согласно прейскуранту.
Очень верное замечание.
Однако, есть две вещи, которые лично меня приводят в бешенство:
— написание выражений без пробелов:
— смешение табуляции и пробелов в одном исходном файле.
Уж не знаю почему. Но когда я вижу такое в коде подчиненных, то заставляю переделывать.
А смесь пробелов и табуляции -- это вообще как свидетельство того, что человек не владеет инструментами, которыми пользуется (не способен настроить свой редактор/IDE).
Упс... Чо-то прорвало меня.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, landerhigh, Вы писали:
E>>Из всех рекомендаций по оформлению кода, которые мне приходилось видеть эти, пожалуй, самые лояльные. L>У меня сложилось впечатление, что после определенного числа проектов и связанных с ними развлечений, любой программист приходит к более-менее такому же набору правил.
Это само собой.
Просто когда приходят в проект новички, приходится тратить время, убеждая их, что надо делать так, а не иначе — у них же нет такого опыта.
Вот в этом смысле им очень полезно дать эту книжку почитать.
eao197 пишет:
> А смесь пробелов и табуляции -- это вообще как свидетельство того, что > человек не владеет инструментами, которыми пользуется (не способен > настроить свой редактор/IDE).
А я вот вполне осознанно пробелы с табуляцией мешаю Не знал, что это
может кого-то бесить...
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[17]: Google C++ Style Guide
От:
Аноним
Дата:
04.07.08 08:22
Оценка:
Здравствуйте, jazzer, Вы писали:
J>Это само собой. J>Просто когда приходят в проект новички, приходится тратить время, убеждая их, что надо делать так, а не иначе — у них же нет такого опыта. J>Вот в этом смысле им очень полезно дать эту книжку почитать.
Вот прихожу я, новичок, в проект (точнее, в небольшую фирму, занимающуюся небольшими проектами), мне разъясняют, что пробелы и скобки ставить так-то, что тернарный ?: не использовать, что ссылки применять только по требованию синтаксиса (читайте: при переопределении операторов и copy-ctor'а), что исключения -- это зло... Ладно, делаю как сказали.
Прошло полгода, и мне досталось "посопровождать" проект, ведомый этим "старшИм", пока он отдыхает в тёплой стране. Когда мне пришлось вносить изменения, то я увидел сплошной copy-paste (строк по 50), а также абсолютно денормализованную БД.
после беглого прочтения не понял следующего
>> If you actually need pointer semantics, scoped_ptr is great. You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr.
>> Use streams only for logging.
чем им не угодили потоки и auto_ptr?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Windows XP 5.1.2600.131072 ... абсолютная тишина
CTpaHHoe пишет:
>> > If you actually need pointer semantics, scoped_ptr is great. You > should only use std::tr1::shared_ptr under very specific conditions, > such as when objects need to be held by STL containers. You should never > use auto_ptr. > >> > Use streams only for logging. > > чем им не угодили потоки и auto_ptr?
Видимо, просто мало кто знает как работает auto_ptr — а работает он
неочевидно. Ну а потоки медленные наверное просто.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, jazzer, Вы писали:
J>неудобно, но все же лучше, чем в какой-нть джаве, где исключения есть, а RAII нет
Уж лучше исключения + GC без RAII чем с кодами возврата жить.
Тем более что есть try/finally а в C# вобще using не сильно хуже RAII получается.
А я сейчас додумываю метод управления жизнью критичных объектов (за не критичными пусть GC смотрит) более гибкий и эффективный чем RAII.
Но это конечно уже не для С++.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sergey, Вы писали:
>> А смесь пробелов и табуляции -- это вообще как свидетельство того, что >> человек не владеет инструментами, которыми пользуется (не способен >> настроить свой редактор/IDE).
S>А я вот вполне осознанно пробелы с табуляцией мешаю Не знал, что это S>может кого-то бесить...
Не подскажете, в каких случаях это может пригодиться? Как именно расставляются пробелы и табуляции, систематически?
Дело в том, что если их расставлять как попало, то кому-то другому, который будет смотреть этот код, придётся временно выставить размер табуляции в тот, который использовался при написании кода, что бывает не удобно.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, jazzer, Вы писали:
J>>неудобно, но все же лучше, чем в какой-нть джаве, где исключения есть, а RAII нет WH>Уж лучше исключения + GC без RAII чем с кодами возврата жить. WH>Тем более что есть try/finally а в C# вобще using не сильно хуже RAII получается.
ну, на мое имхо — сильно хуже, потому что в RAII деструкторы регистрируются по мере добавления, а с finally их наод в одном месте все создавать, флажки всякие заводить, нужно откатывать или не нужно, и все такое. С RAII это все автоматом, пишешь и не думаешь ни о чем, можешь в любой момент в любом порядке все пеетасовать.
)
