— А если не будут брать — отключим газ!
("Бриллиантовая рука")
Рука Феллини…
И началось кино. В смысле - цирк!
Потому что кто кого играет - не понять. Звука нет, одна музыка.
Изображение, правда, есть. Но не цветное, а черно-белое. Причем белого мало.
А потом и черное пропало.
Вот как оно пропало, одна замша и говорит:
- Это же надо, какие съемки! Прямо Лелюш!
И все вокруг тоже шепчут:
- Какой Лелюш! Какой Лелюш!
И ткачиха мне тоже говорит:
- Какой нахал!
Я ей хотел сказать, что я тут ни при чем, просто съемки такие - не видишь,
куда руку кладешь... Тут как раз снова изображение появилось.
Только зря оно появилось, потому что звук пропал. Тут какой-то парик опять говорит:
- Это ж надо, какой монтаж! Прямо-таки рука Феллини!
И все опять:
- Рука Феллини! Рука Феллини!
(М. Мишин)
Какое классное обсуждение. Вставлю и я свои 5 копеек))
Нет плохой технологии, есть плохие программисты, не умеющие её использовать по назначению. И которые вместо того чтоб разобраться - начинают рассказывает какая технология плохая.
В ооп есть минусы, но и в программировании без него тоже. Поэтому то что вы 1 сторону принижаете - выглядит весьма странно и глупо.
Насколько помню, Алан брал за пример живые клетки и немного расстроился не из-за того, что ООП стало данью моде иногда в ущерб задаче, а что лишний акцент именно на отдельных объектах (“клетках”), а не на коммуникации объектов в целом - связях и сообщениях между объектами.
Хорошо, возьмём обычное решение квадратного уравнения.
Что вы подумаете, увидев в объявлении более семи переменных типа integer, и что как real или complex? О чём подумаете, если все параметры объявлены как массив? Если дискриминант вынесен как функция? Если будет переменная viet?
Хотя главное - правильный и своевременный результат, даже объявление переменных демонстрирует подготовку, предпочтения и направленность. К лучшему или же зря, но в современном стиле Pascal Abc . Net теряется такая наглядность.
Никто не запрещает вам объявлять переменные, чтобы сохранить результат. Даже в современном стиле. Я и сам так делаю, если есть упор на производительность (LINQ, лямбды и кортежи штуки медленные (относительно)). Но вот глобально сохранять результаты промежуточных подпрограмм (таких, как дискриминант или виет) — это говнокод на любом языке.
По моему, это всё звучит слишком абстрактно. По делу есть 2 вещи которые все по чуть чуть говорили, но не подробно и не сильно разделяя их:
Глобальные переменные (в var секции которая НЕ между begin и end) - это сущее зло! Они работают в разы медленнее локальных. Во сколько зависит от процессора правда, ибо всё ускорение локальных идёт от того - что содержимое стека кешируется в самом процессоре.
Область видимости у переменной должна быть там - где её можно использовать. Иначе это тоже говнокод:
begin
// не существует
begin
// не существует
var i := 0;
// существует
end;
// не существует
end.
На самом деле, в IL кодах - все локальные переменные объявляются в заголовке метода. Но в современном программировании, объявление переменных в заголовке - это ужасный стиль, от которого уходят все языки программирования.
Он провоцирует дальнейший говнокод + как раз узнать зачем нужна переменная, когда она объявлена не на месте использования, а в общей мусорке - только сложнее.
Что я так же не сказал про глобальные (потому что сначала нужно было 2.) - это то, что конечно, переменные существующие не зависимо от того, что сейчас выполняется - нужны. Но для этого надо использовать статичные поля классов.
Глобальные переменные, на самом деле - тоже статичные поля. Но если вы делаете своё статичное поле - вы так же указываете его видимость и объявляется его в контексте, в классе - в котором есть статичные (и может не только) методы, использующие это поле. Что помогает понимать зачем и где нужна переменная.
А так же избавляет от нужны делать длиннющие названия, ибо в каждом статичном классе - своя область уникальных имён, с именами из других классов они не пересекаются.
Ну и ещё у статичных полей есть плюшки вроде [ThreadStatic]… То есть вся мощь .Net, в то время как глобальные переменные могут только существовать.
Если коротко - пойму, из какого места растут руки у того, кто такой код написал.
Но кто мешает написать хотя бы вот так:
begin
Println('Нахождение корней уравнения ax^2+bx+c=0');
var (a, b, c) := ReadReal3('Введите коэффициенты a,b,c:');
if Abs(a) < 1e-16 then Println('Уравнение вырожденное')
else
begin
var D := b * b - 4 * a * c;
if D > 0 then
begin
D := Sqrt(d);
var x1 := (-b - D) / 2 / a;
var x2 := (-b + D) / 2 / a;
$'x1={x1}, x2={x2}'.Println
end
else
if D = 0 then $'x={-b/2/a}'.Println
else
begin
var cD := Sqrt(complex(D));
var x1 := (-b - cD) / 2 / a;
var x2 := (-b + cD) / 2 / a;
$'x1={x1.ToString}, x2={x2.ToString}'.Println
end
end
end.
И что, в приведенном коде много переменных? Кто-то может не понять, что они обозначают и какой имеют тип? Такое описание переменных ухудшает наглядность использованного алгоритма? Увеличивает количество использованных переменных? В чем проблема-то?
Спасибо, Сергей, трезво. Только лишь два уточнения:
в теме “Замечаний и предложений” вопрос касался выделения таких разрозненных объявлений, чтобы они цепляли глаз по коду. (Позже я заметил, что в режиме трассировки появляется вкладка локальных переменных, хотя и без возможности перейти к конкретному месту)
мой же вопрос в этой теме касался именно способности оценить будущий код известной задачи по “ингредиентам” (использованным переменным), что вполне под силу даже “среднячку”, знакомому с традиционным решением.
Александр, так и я о том же: в отличие от россыпи объявлений с автотипом, которое часто не улучшает читабельность, особенно на фоне спагетти-кода и конструкций вида:
begin
begin var a:=5 ... end;
...
for var a:=-1000 to 1000 do ...;
...
var a:='6';
end.
список ингредиентов-переменных помогает организовать процесс и определить качество реализации.
Это к продолжению темы об экстрасенсах? Такие оценки - они крайне непрофессиональны и цель их абсолютно неясна.
И? Вас смущает, что некто использовал переменную “a” в разных контекстах? Если это оправдывается алгоритмом - почему нет? Если не оправдывается - это пример того самого г**нокода.
Без эталона, стандартов и метрики сложно что-то объективно оценить. Однако, разве по виду, вкусу, температуре, времени (ожидания или готовки), ингредиентам, цене и прочим измеримым показателям нельзя хотя бы приблизительно сказать, что с блюдом что-то не так? Тогда почему по-аналогии нельзя сравнить свой вариант по эффективности с другим и выявить лишние и неправильные действия?
Лично мне Паскаль помогал планировать: что, сколько, почему и для чего нужно, обосновывая каждое действие и урезая лишнее. Хорошо, что есть дебугер, а то, видимо, тоже скоро могу зага**окодить, лишь бы хоть как-то работало…
Вот! Наконец-то я понял! У Вас подход к методологии программирования из времен, когда после ассемблера или машинных кодов человек “вырвался” … на просторы языка Fortran. У меня тоже когда-то так было - в середине 80-х, на ЕС ЭВМ. Это вполне нормальный подход… но для того времени. С тех пор много всего изменилось, появлялись новые языки, новые парадигмы. Приобщайтесь! Останавливаться в познании в нашем деле подобно смерти.
Сейчас времена иные.
Кого заботит, какой код у Винды, если она так мучается?
Мы абстрактно говорим об идеальном коде, в котором всё правильно описано и написано.
А он не работает. Или работает не туда (то есть криво).
Начинать нужно с алгоритма, то есть смотреть в корень.
А правильно расписать код - это каллиграфия.
Говнокод - это первый этап эволюции.
Даже правильные программисты произошли от обезьяны.
Эталон - это идеал, который недостижим.
Есть определённые правила, которые пришли из правды и прозы жизни.
Правила - не законы, их можно не соблюдать.
Но этикет следует соблюдать, и не говнокодить из понятного желания нагадить окружающим.
В данном случае я бы предложил выработать определённые нормы написания и оформления кода на паскале, которые желательно/рекомендательно выполнять.
Впрочем, в рекомендациях разработчиков эти нормы чётко обозначены.
Мы, конечно, вправе что-то посоветовать им. А все остальным - следовать.