Вот, работаю в комании, где практикуют чистый С и
Kernighan & Richie coding style впридачу.
Комментарии — только /* */,
объявления переменных — только в начале функций или блоков,
ну и прочие прелести. В общем, чтобы на самом старом компиляторе
можно было бы собрать.
Насколько оправдан такой подход сейчас ?
Мне казалось, что GCC уже прошелся победным маршем по всем
возможным платформам и такое сейчас просто не оправдано.
Здравствуйте, MasterZiv, Вы писали:
MZ>Вот, работаю в комании, где практикуют чистый С и MZ>Kernighan & Richie coding style впридачу.
MZ>Комментарии — только /* */, MZ>объявления переменных — только в начале функций или блоков, MZ>ну и прочие прелести. В общем, чтобы на самом старом компиляторе MZ>можно было бы собрать.
MZ>Насколько оправдан такой подход сейчас ? MZ>Мне казалось, что GCC уже прошелся победным маршем по всем MZ>возможным платформам и такое сейчас просто не оправдано.
MZ>(я уже не говорю о использовании С++ вместо С).
Могу только посочувствовать.
Меня тут пытаются заставить писать вот так:
MZ>Вот, работаю в комании, где практикуют чистый С и
Круть! Давно мечтал сходить в музей по программированию! MZ>Kernighan & Richie coding style впридачу.
главное чтоб он был, а какой неважно
Здравствуйте, MasterZiv, Вы писали:
MZ>Мне казалось, что GCC уже прошелся победным маршем по всем MZ>возможным платформам и такое сейчас просто не оправдано.
У нас похожий подход применяется. С комментариями, правда, попроще
А обусловлено тем, что все-таки не для всех target-платформ есть компилятор gcc C, не говоя уже о g++.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
MZ>Вот, работаю в комании, где практикуют чистый С и MZ>Kernighan & Richie coding style впридачу.
....
Так писали и до сих пор пишут в Microsoft.
Можете посмотреть исходники свежайшего драйвера FAT.
Здравствуйте, MasterZiv, Вы писали:
MZ>Вот, работаю в комании, где практикуют чистый С и MZ>Kernighan & Richie coding style впридачу.
Все зависит от задачи. Во-первых, С пошустрее, а уж если С++ коряво используемый, так и гораздо пошустрее. Во-вторых, программу гораздо легче читать, если переменные описаны в начале блока, это уж зависит от привычек, но я так и на С# сейчас пишу.
Здравствуйте, dimavs, Вы писали:
D>Все зависит от задачи. Во-первых, С пошустрее, а уж если С++ коряво используемый, так и гораздо пошустрее.
Крайне спорно D>Во-вторых, программу гораздо легче читать, если переменные описаны в начале блока, это уж зависит от привычек, но я так и на С# сейчас пишу.
ИМХО, наоборот тяжелее.
Здравствуйте, Аноним, Вы писали:
D>>Во-вторых, программу гораздо легче читать, если переменные описаны в начале блока, это уж зависит от привычек, но я так и на С# сейчас пишу. А>ИМХО, наоборот тяжелее.
Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, kaa.python, Вы писали:
ДД>>Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все
KP>так же спорный вопрос. функция больше 15-20 строчек уже не совсем желательна.
Зависит от того, в какой среде разработка ведется и какие требования к оформлению кода. Я стараюсь придерживаться такого правила: функция должна занимать не более 3/4 высоты редактора и содержать не более 3 вложенных конструкций.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
dimavs пишет:
> используемый, так и гораздо пошустрее. Во-вторых, программу гораздо > легче читать, если переменные описаны в начале блока, это уж зависит от > привычек, но я так и на С# сейчас пишу.
Это от привычек не зависит. Программу легче читать, если переменная
объявляется в месте первого использования. Ты знаешь, сколько
у нас тут НЕИСПОЛЬЗУЕМЫХ ПЕРЕМЕННЫХ ?
Здравствуйте, MasterZiv, Вы писали:
MZ>Насколько оправдан такой подход сейчас ?
Кодинг-стайл — это кодинг-стайл. Не нравится — обращайтесь к старшему. Но следовать ему — must have. Иначе будет ситуация сродни автодорогам: есть ПДД, но каждый ездит по понятиям. А они у каждого свои, вот и уносит по 30 тыщ в год на кладбище.
Здравствуйте, MasterZiv, Вы писали:
MZ>ДимДимыч пишет: >> Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все
MZ>Функции у нас бывают по 1000-1500 строк.
а вот это гораздо хуже объявлений всех переменных в начале блока и комментариев /* */
Здравствуйте, MasterZiv, Вы писали:
>> А обусловлено тем, что все-таки не для всех target-платформ есть >> компилятор gcc C, не говоя уже о g++.
MZ>Пример можешь привести ?
С которыми сталкивался лично: PIC18FXX2, 8086.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)