Вот, работаю в комании, где практикуют чистый С и
Kernighan & Richie coding style впридачу.

Комментарии — только /* */,
объявления переменных — только в начале функций или блоков,
ну и прочие прелести. В общем, чтобы на самом старом компиляторе
можно было бы собрать.

Насколько оправдан такой подход сейчас ?
Мне казалось, что GCC уже прошелся победным маршем по всем
возможным платформам и такое сейчас просто не оправдано.

(я уже не говорю о использовании С++ вместо С).

Здравствуйте, MasterZiv, Вы писали:

MZ>Вот, работаю в комании, где практикуют чистый С и
MZ>Kernighan & Richie coding style впридачу.

MZ>Комментарии — только /* */,
MZ>объявления переменных — только в начале функций или блоков,
MZ>ну и прочие прелести. В общем, чтобы на самом старом компиляторе
MZ>можно было бы собрать.

MZ>Насколько оправдан такой подход сейчас ?
MZ>Мне казалось, что GCC уже прошелся победным маршем по всем
MZ>возможным платформам и такое сейчас просто не оправдано.

MZ>(я уже не говорю о использовании С++ вместо С).

Могу только посочувствовать.
Меня тут пытаются заставить писать вот так:

if (...) {
  //...
}

так я прям сопротивляюсь всеми фибрами души.

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 строчек, тогда нормально все

Здравствуйте, ДимДимыч, Вы писали:

ДД>Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

так же спорный вопрос. функция больше 15-20 строчек уже не совсем желательна.

Здравствуйте, kaa.python, Вы писали:

ДД>>Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

KP>так же спорный вопрос. функция больше 15-20 строчек уже не совсем желательна.

Зависит от того, в какой среде разработка ведется и какие требования к оформлению кода. Я стараюсь придерживаться такого правила: функция должна занимать не более 3/4 высоты редактора и содержать не более 3 вложенных конструкций.

korzh.pavel пишет:

> if (...) {
> //...
> }

Ага, вот так и пишем
Это какой-то там древний BSD -convention — :-!

ДимДимыч пишет:
> А обусловлено тем, что все-таки не для всех target-платформ есть
> компилятор gcc C, не говоя уже о g++.

Пример можешь привести ?

dimavs пишет:

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

Это от привычек не зависит. Программу легче читать, если переменная
объявляется в месте первого использования. Ты знаешь, сколько
у нас тут НЕИСПОЛЬЗУЕМЫХ ПЕРЕМЕННЫХ ?

ДимДимыч пишет:
> Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

Функции у нас бывают по 1000-1500 строк.

Здравствуйте, MasterZiv, Вы писали:

MZ>Насколько оправдан такой подход сейчас ?

Кодинг-стайл — это кодинг-стайл. Не нравится — обращайтесь к старшему. Но следовать ему — must have. Иначе будет ситуация сродни автодорогам: есть ПДД, но каждый ездит по понятиям. А они у каждого свои, вот и уносит по 30 тыщ в год на кладбище.

Здравствуйте, MasterZiv, Вы писали:

MZ>Функции у нас бывают по 1000-1500 строк.
в совокупности с объявлением переменных в начале это мега

Здравствуйте, MasterZiv, Вы писали:

MZ>ДимДимыч пишет:
>> Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

MZ>Функции у нас бывают по 1000-1500 строк.

а вот это гораздо хуже объявлений всех переменных в начале блока и комментариев /* */

Здравствуйте, MasterZiv, Вы писали:

>> А обусловлено тем, что все-таки не для всех target-платформ есть
>> компилятор gcc C, не говоя уже о g++.

MZ>Пример можешь привести ?

С которыми сталкивался лично: PIC18FXX2, 8086.

ДимДимыч пишет:

> С которыми сталкивался лично: PIC18FXX2, 8086.

Можно поподробнее ?
На счет 8086 — все понятно, но не верю, что они еще остались.
Остались ? И что там за ОС ? ДОС ? И нет GCC под дос ?

Здравствуйте, MasterZiv, Вы писали:

MZ>Ага, вот так и пишем
MZ>Это какой-то там древний BSD -convention — :-!

Это было оправдано во времена алфавитных дисплеев, когда на экране умещалось очень мало текста.