Как перестать программировать на С++ в Паскаль стиле?

← →
ZeroDivide © (2009-05-17 00:53) [80]

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

А ты уверен, что ты хочешь у них работать?
Я б задумался.

А что, с вакансиями по Delphi, совсем туго стало?

← →
Германн © (2009-05-17 01:06) [81]

> ZeroDivide © (17.05.09 00:53) [80]
>
>
> > Но мы в затруднении, т.к. сейчас ты будешь программировать
> > на С++ в паскаль стиле,
> > а для нас это не приемлемо
>
>
> А ты уверен, что ты хочешь у них работать?
> Я б задумался.
>

+1
И не потому, что привержен стилю Дельфи. А потому что не привержен никаким стилям!
Но х.з. на что обратили внимание принимавшие примеры кода и собеседование. Может у них и есть веские причины отказать. Причины не фундаментальные, но для именно них - веские!

← →
Игорь Шевченко © (2009-05-17 01:46) [82]

> Iif в данном конкретном случае, был бы более читабелен,
> имхо. Или IsNull.

Iif нечитабелен вовсе.

Вместо Company != null можно написать !Company.IsUnnamed и IsNull уже не подходит.
А вот оператор ? : подходит во всех случаях. Его не зря придумали, вовсе не для того, чтобы засорить мозги рабочему классу.

← →
Mystic © (2009-05-17 02:20) [83]

Он то подходит во всех случаях, но часто мне приходилось втыкать в него, что же там происходит. Во-вторых, часто при изменении кода мне приходилось заменять ? : на обычный if и наоборот. А в одном случае было, что я за день в одном месте раза три одно на другое. В-третьих надо помнить его приоритет. А Iif предоставляет привычную функциональную запись. Так что это во многом это вопрос вкуса.

← →
Игорь Шевченко © (2009-05-17 02:58) [84]

Mystic © (17.05.09 02:20) [83]

> но часто мне приходилось втыкать в него, что же там происходит

Это нисколько ни умаляет достоинств оператора.

Повторюсь еще раз - функциональная запись и запись условного оператора с точки зрения "втыкабельности" являются настолько разными, что обуждать всерьез замену условного оператора функциональной записью есть сугубо бесперпективное занятие.

> В-третьих надо помнить его приоритет

Или взять в скобки, если приходится использовать такие конструкции, где приоритет непонятен при простом чтении.

Впрочем, программу на Фортране можно написать на любом языке программирования - было бы желание.

← →
Mer (2009-05-17 07:34) [85]

> [80] ZeroDivide © (17.05.09 00:53)
> А что, с вакансиями по Delphi, совсем туго стало?

Хм. С ними всегда туго было.
На Дельфи больших игр не делают.

← →
Alex Konshin © (2009-05-17 07:53) [86]

> Игорь Шевченко © (17.05.09 02:58) [84]
> Mystic © (17.05.09 02:20) [83] > но часто мне приходилось
> втыкать в него, что же там происходитЭто нисколько ни умаляет
> достоинств оператора.Повторюсь еще раз - функциональная
> запись и запись условного оператора с точки зрения "втыкабельности"
> являются настолько разными, что обуждать всерьез замену
> условного оператора функциональной записью есть сугубо бесперпективное
> занятие.

Я ещё раз повторю: между ?: и любыми попытками его эмулировать функциями всегда есть принципиальная разница потому, что в любой функции все аргументы вычисляются всегда. Если непонятно о чём я, то попытайтесь представить в фунциональной форме тот же пример, что я приводил (очень, кстати, частый случай употребления этого оператора):
item = array==null ? null : array[0];

← →
Mystic © (2009-05-17 11:24) [87]

> Я ещё раз повторю: между ?: и любыми попытками его эмулировать
> функциями всегда есть принципиальная разница потому, что
> в любой функции все аргументы вычисляются всегда.

Конечно я это знаю, но лично у меня такая ситуация возникает, мягко сказать, достаточно редко, чтобы принимать это во внимание.

← →
Григорьев Антон © (2009-05-17 15:15) [88]

> Alex Konshin © (17.05.09 07:53) [86]
> Я ещё раз повторю: между ?: и любыми попытками его эмулировать
> функциями всегда есть принципиальная разница потому, что
> в любой функции все аргументы вычисляются всегда.

Если функция будет встроенной, то за счёт compiler magic может и не вычисляться. А вот функциональная форма записи в данном случае действительно читабельнее будет.

← →
Игорь Шевченко © (2009-05-17 15:30) [89]

> А вот функциональная форма записи в данном случае действительно
> читабельнее будет.

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

← →
@!!ex © (2009-05-17 15:55) [90]

> [89] Игорь Шевченко © (17.05.09 15:30)

Так ведь функциональне языки прекрасно работают... и нет никаких проблем.

← →
AndreyV © (2009-05-17 16:24) [91]

> [88] Григорьев Антон © (17.05.09 15:15)
> Если функция будет встроенной, то за счёт compiler magic
> может и не вычисляться. А вот функциональная форма записи
> в данном случае действительно читабельнее будет.

Не ройдёт - стандарт говорит, что должно всё вычислится и это правильно, мало ли что там делается. Не делать же исключение для iif().

← →
AndreyV © (2009-05-17 16:27) [92]

> [91] AndreyV © (17.05.09 16:24)
> Не ройдёт - стандарт говорит, что должно всё вычислится
> и это правильно, мало ли что там делается. Не делать же
> исключение для iif().

Сам вижу грамматические ошибки.

← →
Игорь Шевченко © (2009-05-17 16:56) [93]

> Так ведь функциональне языки прекрасно работают... и нет
> никаких проблем.

с читабельностью ?
ассемблер тоже прекрасно работает

← →
Alkid © (2009-05-17 17:32) [94]

> Игорь Шевченко © (17.05.09 16:56) [93]
> с читабельностью ?
> ассемблер тоже прекрасно работает

Это вопрос привычки. Я не пропагандирую липсовский синтаксис (хотя у него есть свои плюсы), но есть язык и с весьма читаемым кодом. Например, тот же Хаскель. Или Эрланг.

← →
Игорь Шевченко © (2009-05-17 19:40) [95]

Alkid © (17.05.09 17:32) [94]

> Это вопрос привычки

Если кто не заметил, в сабже идет речь о Паскале и С

← →
Alkid © (2009-05-17 21:58) [96]

> Игорь Шевченко © (17.05.09 19:40) [95]
> Если кто не заметил, в сабже идет речь о Паскале и С

Сарказм не уместен. Тема расширилась, раз уж упоминаются функциональные языки и ассемблер :)

> Игорь Шевченко © (17.05.09 15:30) [89]
> а давай вообще все конструкции языка на функциональную запись
> переведем - чтобы врагам, упершим код, страшно стало.

Кстати, такие языки как Lisp и Prolog используют в высшей степени регулярные синтаксисы (у лиспа регулярнее, у пролога - выразительнее). Однако после первой адаптации (восновном у лиспа) его код прекрасно читается.

← →
Игорь Шевченко © (2009-05-17 22:26) [97]

Alkid © (17.05.09 21:58) [96]

> Сарказм не уместен

Вполне себе уместен, бо основная дискуссия развернулась в обсуждение "втыкабельности" оператора ? : для тех, кто привык программировать на паскале.

А наиболее читабельными языками являются, разумеется, perl и APL

← →
Германн © (2009-05-18 01:36) [98]

> Игорь Шевченко © (17.05.09 22:26) [97]
>
> Alkid © (17.05.09 21:58) [96]
>
>
> > Сарказм не уместен
>
>
> Вполне себе уместен, бо основная дискуссия развернулась
> в обсуждение "втыкабельности" оператора ? : для тех, кто
> привык программировать на паскале.
>
> А наиболее читабельными языками являются, разумеется, perl
> и APL

А для меня - ассемблер!
Но у меня и задачи другие. А вот про задачи - это иной вопрос!
:)

← →
KilkennyCat © (2009-05-18 01:53) [99]

Все херня. Похрен гдже, что и на чем. Истинному спецу похрен. Беда лишь в том, что истинный спец сродни художнику - олценят, когдва сдорхнешщь. Выбора два - делать денги, или делать качественно.

← →
KSergey © (2009-05-18 06:16) [100]

> KilkennyCat © (18.05.09 01:53) [99]
> Выбора два - делать денги, или делать качественно.

У всех "творцов" есть изъян: они жрать хотят. При этом часто не отвечая за наличие результата.
Так что должно быть и быстро, и качественно. "Вольные художники" - это раздолбаи.

← →
Alkid © (2009-05-18 09:14) [101]

> KilkennyCat © (18.05.09 01:53) [99]
>
> Все херня. Похрен гдже, что и на чем. Истинному спецу похрен.
> Беда лишь в том, что истинный спец сродни художнику - олценят,
> когдва сдорхнешщь. Выбора два - делать денги, или делать
> качественно.

Не согласен. Промышленное производство гамнокода себя не оправдывает в стратегической перспективе. Не раз уже наблюдал, как разработки загибаются из-за того, что старый код не дает развиваться, поскольку написан через Ж.

← →
Mer (2009-05-18 10:24) [102]

> [101] Alkid © (18.05.09 09:14)

Вам попадаются клевые заказчики, если они это понимают!
Мне в основном попадаются:
"Надо сделать быстро, месяца за четыре. Сроки поджимают... Быстро! Быстро! Быстро!"
И это на проект, который в течении ближайших лет должен расширяться активно...
ВОт только БЫСТРО и КАЧЕСТВЕННО вещи не очень то совместимые.
Проект практически сделан.
По хорошему надо еще месяц два потратить на рефакторинг и вылизывание кода.
Вот только заказчик не хочет тратить время и деньги. Заказчик хочет РЕЗУЛЬТАТ.

← →
SPeller © (2009-05-18 11:06) [103]

Я когда писал на php постоянно использовал оператор ? и ничего, удобно местами. На дельфе не испытываю неудобств от его отсутствия. Что я делаю не так? :)

← →
Медвежонок Пятачок © (2009-05-18 11:13) [104]

Вот только заказчик не хочет тратить время и деньги. Заказчик хочет РЕЗУЛЬТАТ.

Какой направильный заказчик. Правильный заказчик должен хотеть не результат, а процесс.

← →
Alkid © (2009-05-18 11:13) [105]

> Mer (18.05.09 10:24) [102]

Заказная разработка вообще этим сильно страдает и там с этим труднее. Мне пришлось поплюхаться с этим на первой работе. Потом я работал в фирмах, которые делают коробочный софт, там положение дел зависит не от уровня понимания клиента, а от уровня понимания начальства. На предыдущей работе производство "быстро и абы как" в определённый момент стало чуть ли не официальной политикой, проводимой на уровне всего департамента разработки. Я оттуда почти сразу уволился :) Сейчас ситуация диаметрально противоположная - мой начальник очень много внимания уделяет качеству кода и дизайна.

← →
Медвежонок Пятачок © (2009-05-18 11:22) [106]

Проект практически сделан.
По хорошему надо еще месяц два потратить на рефакторинг и вылизывание кода.

Уже требуется рефакторинг свеженаписанного проекта?
Скорее требуется тест на профпригодность таких писателей.

← →
Alkid © (2009-05-18 11:27) [107]

> Медвежонок Пятачок © (18.05.09 11:22) [106]
> Уже требуется рефакторинг свеженаписанного проекта?
> Скорее требуется тест на профпригодность таких писателей.

Запросто. Таких ситуаций возникает вагон и тележка - требования поменялись, разработчик скосячил или не знал какой-то информации. Идеальный код с первого раза почти никогда не пишется. Зато потом с дважды-трижды переписанным кодом, вылизанным и обложенным юнит-тестами жить намного легче и дешевле, чем с тем, который write-only :)

← →
palva © (2009-05-18 11:27) [108]

> На дельфе не испытываю неудобств от его отсутствия. Что я делаю не так?

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

Требования меняются часто.
Что это за архитектор, если каждый чих требует ни мало ни много а сразу оринга?

Alkid © (18.05.09 11:27) [107]

> Идеальный код с первого раза почти никогда не пишется.

Все зависит от степени ясности решаемой задачи. Когда задача полностью ясна и осознана, то и код, чаще всего получается если не идеальный, то близкий к нему.

когда задача полностью ясна и написан код, полностью удовлетворяющий ей, это еще не значит, что он близок к идеальному.
он точно так же может быть структурирован так, что малейшее изменение условий задачи потребует того самого пресловутого рефакторинга.

> Mer (18.05.09 10:24) [102]

Да ради бога, если он хочет постоянно платить, а платить ему придется.

> Игорь Шевченко © (18.05.09 11:37) [110]
> Все зависит от степени ясности решаемой задачи. Когда задача
> полностью ясна и осознана, то и код, чаще всего получается
> если не идеальный, то близкий к нему.

Да, это так.
Абсолютно верное замечание.

Качество кода как такового мало связано с качеством и детализацией поставленной задачи.

Задача может быть поставлена крайне туманно и вообще не до конца поставлена. Например : "надо будет обрабатывать (как-то) входные файлы (где-то) и делать с ними что-то (потом скажу что)."

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

> [115] Медвежонок Пятачок © (18.05.09 12:49)

Huh! Можно посмотреть примеры реализованных вами задач?
Просто ИМХО такое заявление говорит о практически полном отсутствии опыта в проектировании действительно сложных задача в сжатые сроки.
В первую очередь потому, что есть два варианта развития проекта:
1) Полная унивресальность. Этот подход ну никак не укладывается в разумные сроки.
2) Решение конкретной задачи с учетом возможных изменений в дальнейшем. Как показывает практика, предсказать на 100% что захочет заказчик в будущем - невозможно, а значит и заложить возможность тоже. Иногда пожелание заказчика очень сложно реализуемо в рамках разработанной архитектуры. А значит либо портим код, либо все переписываем. Второе исключается, потому что сроки сжаты. Вот и получаем на выходе код, который не плохо было бы отрефакторить.

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

Просто ИМХО такое заявление говорит о практически полном отсутствии опыта в проектировании действительно сложных задача в сжатые сроки.
В первую очередь потому, что есть два варианта развития проекта:

Расслабся лучше.

> как перестать писать в Паскаль стиле?

не нажимать шифт в начале идентификатора -)

Вот и получаем на выходе код, который не плохо было бы отрефакторить.

Кто-то получает такой.
А кто-то получает совсем другой код.

Как перестать программировать на С++ в Паскаль стиле? Найти похожие ветки