[LiTr 0]

Если говорить об первоначальной теме топика, не углубляясь в личные предпочтения каждого программиста (кому-то удобнее писать используя одни функции языка, другому - другие, программы обоих могут быть одинаково эффективны). Я так понимаю, автора интересовал вопрос о грамотном написании встраиваемого ПО. Чтож, о том, что эта область не затрагивается - убеждение ошибочное, просто она не столь широко освещается. В общем и целом проектирование ПО для МК аналогично тому же для ПК, с некоторыми исключениями, например необходимостью учитывать особенности аппаратной платформы и т.п. Есть и литература по данному вопросу, первое что пришло на ум - Ален И. Голуб, у него есть несколько работ по данной тематике, но к топику наиболее подходит его книга "Веревка достаточной длинны, чтобы... выстрелить себе в ногу" (и название говорящее...).

Тут кто-то сказал, что печально слышать от программиста: "это очень сложно" и "этого в ТЗ небыло", а программисту по-вашему приятно слышать "о а давай-ка мы тут новую штуку добавим" или "ну мы думали что будет нормально, а нам не подходит - надо переделать". Вот строите вы дом, а к вам подходит заказчик и говорит: "Гм... что-то не то... а давайте мы вот тут на первом этаже дырку в стене прорубим и поставим большое окно!" сделать можно что угодно, вот только дом потом развалится. Тогда уже вопрос не в проектировании ПО а в управлении проектом в целом.

Возвращаясь к теме: сложно дать конкретную доктрину по проектированию ПО для МК, тем более не ясно какой именно аспект этого проектирования Вас интересует. Единственное что можно посоветовать: ищите, ищите и еще раз ищите. А лучше поучится у тех у кого большой опыт ведения проектов по разработке встраиваемых систем.

[kojevnikov 0]

Вообще-то этот топик не про оператор goto, а про проектирование ПО. Оператор goto ни как не относится к пректированию, он больше относится больше к реализации. Я этим оператором никогда не пользовался, потому что еще в институте меня учили, что это правило плохого тона, а я этого понять не мог (почему плохого?). Смысл всего этого я понял намного позже, когда начал разбираться с чужой программой, которая была усыпана goto. Оператор goto снижает видимость кода, мысли частенько начинают теряться, если код большой, метка и оператор находятся далеко друг от друга. При исследовании такого кода крышу слегка срывает. Ну и с переносимостью такого кода тоже возникают проблемы. Хотя можно и на ООП написать так, что ни чего ни куда не перенесешь. Все зависит от опыта программиста... Руки у всех разные.

[AlexandrY 2]

А вы вместо notepad-а попробуйте применить Understand и его автоматический генератор диаграмм для анализа исходников, и неожиданно увидите что с goto понятнее получается чем с теми же косвенными переходами.

 

Я этим оператором никогда не пользовался, потому что еще в институте меня учили, что это правило плохого тона, а я этого понять не мог (почему плохого?). ...

Все зависит от опыта программиста... Руки у всех разные.

[kolobok0 0]

...А может кто чего-нибудь подскажет?

 

Прочитал весь топик (типа читал пэйджер - много думал). Как то грустно и смешно (простите).

Народ, а чего Вы повелись то? Автор топика возможно неплохой программист, но как организатор - в начале пути.

Речь свелась к технике. И ещё круче к несчастному оператору (не буду тут его в суе) :) При чём тут вообще это то?

Лично знаю более 10 языков, из них только азмы вызывают теплоту в душе. Наверное благодаря принципу - что сделано, сам дурак. И как то филолетово

кол-во чего то там. Есть красивые решения в технике программирования - вот их и применять нужно.

И КАЖДЫЙ язык имеет свои СИЛЬНЫЕ стороны и КРАСИВЫЕ решения.

И из каждого можно сделать на несколько метров портянки блевотной массы. И чего?

 

А по теме:

Автор - не там ищите.

Я более того скажу - Вы задали вопрос который можно сформулировать немного по другому:

где взять технологию перехода(оптимального, менее затратного в ресурсах и т.д.) от пользовательской задачи к коду.

И так как это _технология_ то согласитесь - тут говорить о языке(оси, железе), мягко говоря - глупо.

какая технология - читайте популярную литературу. как говорится - всё придумано до нас :)

 

автору удачи - она Вам потребуется

(круглый)

[vvs157 0]

Существует такая наука как проектирование ПО. У нас она не очень развита (мое мнение)

Вообще-то на эту тему есть даже международные и отраслевые стандарты (поэтому это не наука, а технология производства), например прогуглите "ISO Standart for software life-cycle proces" или "DOD-STD-2167"

[grau 0]

Существует такая наука как проектирование ПО. У нас она не очень развита (мое мнение), тем более для микроконтроллеров. А может кто чего-нибудь подскажет?

 

Эта штука хорошо сделана у буржуев, некий конвеер, которому все равно, чего разрабатывать. Для понимания, зачем надо и что получается, можно почитать "Совершенный код", Стив Мак-Коннел. Или поработать в конторе с CMMI-3 и выше

[DogPawlowa 0]

И КАЖДЫЙ язык имеет свои СИЛЬНЫЕ стороны и КРАСИВЫЕ решения.

 

Программирование давно уже ремесло, типа умения быстро забивать гвозди.

А в поисках красивых решений можно придти в забиванию гвоздя тупым концом.

[learning_avr32 0]

И КАЖДЫЙ язык имеет свои СИЛЬНЫЕ стороны и КРАСИВЫЕ решения.

100%

 

to Dog Pawlowa: наверное здесь "КРАСИВЫЕ" = "НЕСТАНДАРТНЫЕ", "ЭФФЕКТИВНЫЕ"

P.S. Иногда гвозди затупляют именно для ЭФФЕКТИВНОГО забивания

Изменено 30 марта, 2010 пользователем forever_student

[Bill 0]

Программирование давно уже ремесло, типа умения быстро забивать гвозди.

А в поисках красивых решений можно придти в забиванию гвоздя тупым концом.

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