Сравнение двух стилей программирования

[shau-kote]

venco в сообщении #657801 писал(а):

А вот не-Integer передать в AddElement() невозможно, что именно вы собираетесь проверять?

Я же Вам привёл конкретный пример: я могу передать процедуре LongInt, который успешно будет передан и процедура внешне корректно отработает, хотя результат будет далеко не всегда корректный.
И в Вашем случае программист, работающий извне с процедурой, дурак, и в моём.
Но обработку Вашего случая Вы считаете необходимой, а обработку моего считаете ненужной.

[venco]

Ещё раз: что именно вы собираетесь проверять? Напомню - внутри процедуры AddElement().

[Munin]

shau-kote в сообщении #657794 писал(а):

Надо либо делать функцию, либо вводить дополнительный параметр.
И то, и то неплохо загромождает как основную программу, так и подпрограмму.

Зато является действительно привычкой по написанию хорошего кода. А не просто косметикой.

shau-kote в сообщении #657800 писал(а):

А как же логическое структурирование кода? Упрощение отладки? Повышение гибкости программы? Удобство дальнейшей модификации?

Это всё достигается теми аспектами качества кода, от которых вы как раз хотите увильнуть: тщательным проектированием и реализацией. Одного разбиения функции на подфункции для этого остро недостаточно.

[shau-kote]

venco в сообщении #657811 писал(а):

Ещё раз: что именно вы собираетесь проверять? Напомню - внутри процедуры AddElement().

Хм. Не знаю, право.
Но аварийная ситуация налицо ведь.

Munin в сообщении #657851 писал(а):

Зато является действительно привычкой по написанию хорошего кода. А не просто косметикой.

То есть Вы хотите сказать, что та процедурная декомпозиция, которую я сделал - лишь косметика?
Вам не кажется, что это другая крайность? Как одна крайность - писать код, подобный тому, что я привёл во втором примере в свой первом посте, так другая крайность - пытаться обработать бесчисленное количество ситуаций, который при, так сказать, обдуманном повторном использовании кода никогда и не возникнут? (Отмечу ещё раз: я не говорю о написании автономных универсальных библиотек с интерфейсом "на все случаи жизни".)

Munin в сообщении #657851 писал(а):

Это всё достигается теми аспектами качества кода, от которых вы как раз хотите увильнуть: тщательным проектированием и реализацией. Одного разбиения функции на подфункции для этого остро недостаточно.

Позвольте такой контрпример.
Значительное количество стандартных подпрограмм того же Pascal не занимаются проверкой "возможности корректного выполнения". Та же процедура New(pointer).
Они полагаются на здравомыслие и адекватность программиста.
Вы считаете, это в корне неверно?

[Joker_vD]

shau-kote в сообщении #658012 писал(а):

Но аварийная ситуация налицо ведь.

Какая, я не пойму? Integer и LongInt — это одинаковые типы.

[_Ivana]

shau-kote в сообщении #658012 писал(а):

Как одна крайность - писать код, подобный тому, что я привёл во втором примере в свой первом посте, так другая крайность - пытаться обработать бесчисленное количество ситуаций, который при, так сказать, обдуманном повторном использовании кода никогда и не возникнут?

Имхо, можно рассматривать оптимизацию кода как многокритериальную задачу. Именно поэтому столько много вариантов и ключей у компилятора. Оптимизировать можно по объему полученного скомпилированного кода, объему используемого ОЗУ, скорости выполнения, объему исходного нескомпилированного кода, дуракоусто устойчивости кода к некорректным исходным данным, в т.ч. отдельных процедур и функций, и т.д. вплоть до визуальной красоты. Часто все эти критерии взаимно противоречивы, и выбирать приходится наиболее существенные в каждой конкретной ситуации. От этого, кстати, зависят даже применяемые методы и алгоритмы - некоторые требуют столько ОЗУ, сколько нет в наличии, например.

[shau-kote]

Joker_vD в сообщении #658026 писал(а):

Какая, я не пойму? Integer и LongInt — это одинаковые типы.

Пардоньте, моя ошибка.
Привык, что в Pascal'е эти типы различаются диапазоном на несколько порядков, в то время в Delphi они идентичные. Виноват.
Но суть того, на что я хотел указать не сильно меняется. Допустим, я в объявил поле value как byte, и соответствующим образом объявил все процедуры. Тогда при передаче в процедуру add() Integer'а потенциально возможны проблемы.

[venco]

shau-kote в сообщении #658075 писал(а):

Допустим, я в объявил поле value как byte, и соответствующим образом объявил все процедуры. Тогда при передаче в процедуру add() Integer'а потенциально возможны проблемы.

Вы никак не хотите понять, что проблемы в данном случае - у вызывающего кода, аналогичные простому присваиванию byte переменной integer значения. А процедура add() уже ничего ни диагностировать, ни сделать не может - у неё на входе уже byte.

[shau-kote]

venco в сообщении #658080 писал(а):

А процедура add() уже ничего ни диагностировать, ни сделать не может - у неё на входе уже byte.

Мда. Действительно.
Вы правы, данный случай процедура отследить уже не может.

[rockclimber]

shau-kote в сообщении #657653 писал(а):

Всем доброго времени суток.

Краткая предыстория.
Я помаленьку увлекаюсь программированием уже много лет, с разной интенсивностью.
Соответственно как-то уже выработал привычки по написанию хорошего кода.
А в этом году поступил в крупный технический ВУЗ, на "CS"-специальность.
И столкнулся с массой людей, которые код пишут первый раз и потому пишут его "как могут".
Что заставило меня несколько задуматься о том, насколько ценны те принципы, которые я соблюдаю, уже на задумываясь об их смысле.

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

Мой:
{пропущено}

Не мой:
{пропущено}

Второй почти в полтора раза короче. :\
Думаю, разницу в организации кода объяснять не надо, всё очевидно.

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

(Оффтоп)

Обожаю паскаль! 8-) Первая любовь, так сказать Это на всю жизнь.

Советов вам тут уже много дали.
Я бы сказал так:
1. Куски кода слишком маленькие, чтобы делать далеко идущие выводы
2. Различия минимальные
3. Насколько много вы собираетесь программировать? От этого зависит, что вам посоветовать.
В любом случае посоветую читать этот блог.
Обработку ошибок тут упоминали - вот и про нее есть.

-- 13.12.2012, 23:13 --

А, и еще.
В современных версиях Delphi (а также freepascal) выделением и очисткой памяти управляет менеждер памяти. Я не знаю точно, когда он появился, но появился чуть ли не в самых первых версиях.
То есть вот такой код будет работать корректно и без утечек памяти:

Используется синтаксис Delphi

program list1;

{$APPTYPE CONSOLE}

uses
   SysUtils;

type
   element=record
     value: integer;
     next: integer;
   end;

procedure MyProc;
var
  a: element;
begin
{ Перед выполнением первой инструкции менеджер памяти выделяет память под запись а }
a.value:=10; { здесь не будет access violation, потому что память под запись уже выделена}
a.next:=15;
end; {после выхода из процедуры менеджер памяти вызовет Dispose(a) автоматически }
 

Менеджер памяти не управляет автоматически только объектами (описываются с помощью ключевого слова class).
Советую еще почитать две книги про Delphi. Автор одной - Марко Канту, вторая книга - авторы Пачеко и Тейксейра (вот например).

-- 13.12.2012, 23:17 --

И еще... Эпический холивар на тему "как правильно писать код". Там много треша, выяснения отношений, меряния линейками и прочего, но и правильных мыслей тоже много.

[Munin]

shau-kote в сообщении #658012 писал(а):

То есть Вы хотите сказать, что та процедурная декомпозиция, которую я сделал - лишь косметика?

Не совсем. Но это только начало. Даже к вашей декомпозиции есть вопросы: а почему вы сделали декомпозицию именно так, а не иначе? Если вы сообразите, из каких соображений она проистекает, то из этих же соображений возникнут и другие улучшения.

shau-kote в сообщении #658012 писал(а):

Вам не кажется, что это другая крайность? Как одна крайность - писать код, подобный тому, что я привёл во втором примере в свой первом посте, так другая крайность - пытаться обработать бесчисленное количество ситуаций, который при, так сказать, обдуманном повторном использовании кода никогда и не возникнут? (Отмечу ещё раз: я не говорю о написании автономных универсальных библиотек с интерфейсом "на все случаи жизни".)

Разумеется, я не призываю бросаться в какие-то крайности. Но вы сильно заблуждаетесь, думая, что написание качественного кода и глубокие размышления о предусловиях, инвариантах и возможных вызовах в ошибочных ситуациях нужны только для каких-то супер-универсальных библиотек, а вам не понадобятся. Напротив, вы должны каждую функцию писать, как будто она входит в библиотеку - тогда она станет надёжной основой вашего debuggable и modifiable кода. Собственно, это один из принципов той же декомпозиции: вызываемые модули не должны зависеть от вызывающих, и полагаться на какое-либо их определённое поведение, тогда они будут по-настоящему reusable.

shau-kote в сообщении #658012 писал(а):

Значительное количество стандартных подпрограмм того же Pascal не занимаются проверкой "возможности корректного выполнения". Та же процедура New(pointer).

Вы так думаете?

shau-kote в сообщении #658012 писал(а):

Они полагаются на здравомыслие и адекватность программиста.

Нет, они просто имеют чётко прописанное поведение.

[ewert]

Munin в сообщении #658130 писал(а):

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

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

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

[Munin]

ewert в сообщении #658148 писал(а):

Если нужно быстренько на коленке набросать код

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

Вопрос был о другом: в чём состоят эти привычки, если не стоит такой задачи, какую ставите вы. И вот тут топикстартер пребывает в некоторых иллюзиях.

[Joker_vD]

shau-kote в сообщении #658075 писал(а):

Но суть того, на что я хотел указать не сильно меняется. Допустим, я в объявил поле value как byte, и соответствующим образом объявил все процедуры. Тогда при передаче в процедуру add() Integer'а потенциально возможны проблемы.

Жаль, у меня под рукой нет Delphi, но я почему-то уверен, что если прототип — procedure AddElement(x: Byte);, то вызов AddElement(IntegerVariable) просто не скомпилируется — с ошибкой "no automatic conversion from Integer to Byte".

[ewert]

Joker_vD в сообщении #658175 писал(а):

просто не скомпилируется — с ошибкой "no automatic conversion from Integer to Byte".

Должен скомпилироваться по логике языка (Дельфи -- это всё-таки Паскаль). Он же заранее не знает, байт там выйдет в момент обращения, или два, или ещё сколько. А Паскаль -- он по самому своему замыслу не только жёсток, но и гибок.

Это, конечно, если параметр передаётся по значению. Если по ссылке -- ну тут другой вопрос; тут, конечно -- сливай воду.