@Цецо - с тези разсъждения далече няма да стигнеш (фирмено)..... ами да като определяш програмиста с тестове
А тест за лоялност и доверие имаш ли...

Ами незнам. Сигурно си прав. Няма да стигна далеч, а и не съм тръгнал натам. )))

А твоя опит на какво се базира? На колко души плащаш заплатите?

Няма значение... Идеята беше за Тест на С програмисти...

аз лично работя с хора, които възприемат, а не са дървени глави. в това отношение е по-важен човека, отколкото програмиста. много важно е да се работи с хора, които си знаят къде им е летвата и кога да се "обадят на приятел" за помощ.

на всички, още в началото им давам кратки укзания как очаквам да се пише кода и къде и какви коментари да има.
коментарите са задължително в контекста на doxygen.

някой фатки като тази са изключително полезни, макар да изглеждат странно:
if (8==i) {
...
}

почти е забранено да се правят сложнотии от рода "масиви поинтери към масиви от поинтери към структури". ако наистина се налага, трябва да е изключително детайлно коментирано. поне един път на месец хората си четат кодовете един друг и си правят забележки.

В допълнение на Дедо Боре ( да не се сърди )
има конвенция как да се именуват променливи, константи, функции и т.н. Задължителна, макар че в редки случаи се допускат изключения;
"сложности" от типа b= ++a са забранени - ще го напише с два оператора;
коментарите - там е ясно;
подреждането на кода с модулите също е описано как да се прави и т.н и т.н

Във фирма, където работят много хора, това е задължително да е ПИСАНО правило! И въпреки това, позволено е и "както ти си искаш", но да е изключение, и да е коментирано защо, как и понеже..

И как ще направиш двумерни масиви?

Много е важно като работят много хора по един код да има документиран стандарт за кодиране. Иначе след време някой има да си блъска главата и да благославя първоначалните писачи...
А аз лично предпочитам синтакса

Поне за мен разделянето на първата фигурна скоба прави кода по-очевиден.

@Реконструктор:

не става ли?

Абе и аз това се питах в пьрвия момент. Ама какво става когато не знаеш колко голям масив ще ти трябва.

Има две възможности :
1. Слагаш ограничение на максималния размер на масива, изхождайки от това за какво точно ще го ползваш - по този начин се разхищава малко памет;
2. Динамично заделяне на памет - е тогава не можем да избягаме от указателите. Но пак може да се направи по добър и четлив начин така че да е ясно какво става.

Ами масив 2х2 ти трябва в много малко случаи, бате. Въпроса е кво правим, когато ти трябва масив 2М х 2М ?
Какво правим, когато някоя ф-я трябва да връща указател?

В малка система - един едночипов контролер (с вградени РАМ и РОМ), бил той и АРМ се оказа че рядко има нужда от сложнотии като например масив от указатели от функции; На моменти е удобно .. но общо взето в повечето случаи се гледа какво е оптимално.

В проекта дето търкалям, тръгна да свършва РОМ-а в контролера; съответно наложиха се оптимизации - оказа се че switch/case с извикване на функции ми генерира по-компакетен код, отколкото константен масив от указатели към функции.

Не че не съм правил динамична памет и в AVR

Все пак иде реч за embedded ... макар че е вярно че едно нещо може да се направи по много начини. Аз избирам този, който:
1. Постига целта с приемлив разход на ресурс;
2. Има максимално просто, ясно и изражение, написано на "С"; не обичам да гадая кой си е изсипал великата мисъл в програмката, защото в общия случай излиза по-лесно да се пренапише кода, отколкото да се гадае за странични ефекти. Целта е главно максимална преизползваемост на написания код.

В тази връзка - какво ще кажете за следния код:


Мога само да кажа че доста разбуни духовете на работното място Имаше дълги спорове относно всичките аспекти на неговото съществуване.

ще кажа само, че аз бих го реализирал така


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

Един пресен пример, преди около час седя в упражнение по Основи на Електротехниката и смятаме Лаплас-Трансформации. 3 часа (плюс малко Фурие) и всяка една от задачите можеше да се реши с едно просто диференциално уравнение пьрва или втора степен, Та си мисля аз, не е ли това глупост и прахосване на ценно време.....
Извода обаче е, че така или иначе няма да седна да смятам мрежи с Лаплас, за по-простите проблеми това е малко натруфен метод. Обаче след като познавам метода, може би някой ден с негова помощ ще реша по-сложен проблем, кьдето на останалите методи не им стигат силите.

Изводьт е че, знанието е хубаво нещо, когато се прилага адекватно. Излишното парадиране и себеизтькване по-скоро пречи отколкото помага. В крайна сметка аз сьм ЗА добрия програмист (един натьпкан сьс знания, интелигентен човек винаги ще види повече вьзможни решения на даден проблем), но освен добьр трябва и да е професионалист и човек в крайна сметка. Е това е разликата в моите представи между добрия програмист (и не само) и добрия професионалист.

@HCL: целта на примера е да се илюстрира конструкцията, а не конкретната реализация, например:

printf ("%c",(c+2)["1234567"]);

вече е нещо друго