Читабельность исходников

А вот самый кавайный цикл, который я видел: хоть с предусловием, хоть с постусловием, да ещё и выход не по Break, а в труЪ структурном стайле программирования.

 

нет. ваше определение сахара отличается от общепринятого.
http://www.haskell.org/haskellwiki/Syntactic_sugar
http://en.wikipedia.org/wiki/Syntactic_sugar
сахар не обязательно является урезанной версией другой фичи языка.
сахар это фича которая может быть записана другими менее читабельными (красивыми, удобными) фичами, и при этом сахар не увеличивает мощность языка.

так вот исторически сначала было { int x = 0; while (x != N) { ...; ++x; } }
а потом ввели сахар в виде for(;

нет. точно так же можно утверждать что без виртуальных методов нельзя использовать ООП.
структурное программирование (СП) это парадигма, и она как любая парадигма не зависит от языковых средств.
СП можно реализовать и с помощью if+goto (или jxx\jmp) если придерживаться правил СП

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

говорить "Запись циклов типа 'for i in [1..10]' называется syntactic sugar -- синтаксический сахар" без указания языка некорректно. Потому что существует (может существовать) язык Х в котором for in не является сахаром.
Более того, понятие мощности языка очень расплывчато, потому что читабельность и "писательность" часто имеют большое значение. Мы можем сказать что если без фичи X нельзя сделать того-то, то наличие этой фичи влияет на мощность языка. Так вот например в С++ for(; может влиять на мощность языка, потому что при создании некоторых DSL важно что for(; statement; создает область видимости без использования фигурных скобок - это позволяет писать макросы типа YIELD для coroutines.

 

GoldFinch

А вы считаете, что for(;a<b более читабельна, чем while(a<b)?

Я где-то говорил что нельзя программировать структурно, без структурных конструкций? Я использовал слово "загоняют". И не случайно.

Ооо... Как я ненавижу формалистов и прочих бюрократов с буквоедами. Хорошо! Вы правы. Ваш авторитет непререкаем. И вам +10 к ЧСВ.

 

Wizard109

угу, и на чём писали.

CyberManiac

Компилятор/интерпретатор пусть обрабатывает как написано .

ок, пусть будет:

Код (Text):

1. Fucktion WHEN MyVar
2.      ELSE Function

SadKo
с perl некогда разбираться.
смотрел пайтон, весь синтаксис на день не прочитаешь... но близко к пониманию.

 

r90
термины это такая штука которая требует формального обращения с собой.
так принято.

 

SEC70R_VA

Так у множеств в Паскале/Delphi для элементов нет произвольно определяемого порядка следования, физически это просто битовая карта. Ну и совершенно искусственное ограничение на 256 элементов - это ещё больше мешает жить, ибо set of WideChar ну очень хочется.

 

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

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

Код (Text):

1. int i=5;
2. int j = ++i + ++i;

 

SEC70R_VA

asm, с, с++, с#, Delphi, php, perl, java

Возможно Брэйнфака и Лиспа вопрос о "читабельности" не касается, ибо это полный нимд* но для приведенных языков - абсолютно справедливо.

 

CyberManiac

включите воображение

SadKo

кем бы я ни был, читабельность и понимание исходников зависит не только от написавшего код, но и от выбора языка программирования.
предлагаете Сиплюсплюс чтоле?

например, так можно было бы реализовать CASE, причем масштабируемо от конструкции WHEN, заменяющую IF...THEN...

Код (Text):

1. proc1   WHEN x=0
2.     ELSE proc2 WHEN x=1
3.     ELSE proc3 WHEN x=2

 

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

 

SEC70R_VA
> Почему в классических языках программировании (в императивных в основном),
> вместо, например x:=10 THEN y=1 принято писать IF y=1 THEN x:=10.
наверное, потому что конструкция "если -- то" не только логична, но и совпадает с порядком выполнения инструкций ЦП. попробуйте выполнить такую задачку "СКАЗАТЬ пока-пока ЕСЛИ на стрелках два часа". какая будет последовательность ваших действий?
1) посмотреть на часы
2) если не два часа то (4)
3) сказать "кря"
4) ...

хотя можно так:
1) сказать "кря"
2) посмотреть на часы
3) если два часа, то (5)
4) откат транзакции
5) ...


> ИМХО, {...} FOR i:=[1..10] гораздо читабельней и понятней,
> чем FOR i:=0 TO 10 DO {...}.
опять же, при входе в цикл i неопределена. это раз.
тогда уже for i in [1..10].
хотя for i:=[1..10] хорошо подходит для параллельного программирования и поддерживается достаточно широко. тем же питоном. и смысл такой конструкции (правда, в питоне синтаксис несколько иной) в том, что выполнить { ... } можно при разных значениях i на разных процах одновременно.

> Эти префиксы отвлекают от понимания смысла программы.
ну в питоне вообще минималисты: 'for x in y: print y[x]'
предлагаете что ли писать 'print y[x]: for x in y' -- так у меня крыша поедет.

> Может быть такой язык программирования уже есть?
циклы с пост-условием есть во всех языках (ну вроде бы во всех).

 

Батенька, такого даже в SQL и PL/SQL нет. Разве что в перле:

Код (Text):

1. print "you are Mooduck!\n" if (lc $ARGV[0] eq 'mooduck');

Но за такой код убивать надо, особенно когда condition прячется где-то там за правым краем экрана.

 

SadKo
> Но за такой код убивать надо, особенно когда condition прячется где-то там за правым краем экрана.
убивать. потому что в любом языке можно создать конструкции типа:
f = {proc1:0, proc2:1, proc3:2} и дальше f[x](); а в данном частном случае, даже еще проще: [proc1, proc2, proc3][x]();
оно и понятнее и работает быстрее. и править проще при необходимости.

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

 

kaspersky

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

наверное, макросами можно сделать такое.

SadKo

1920х1080 иметь надо .

 

SEC70R_VA
Вы действительно убеждены, что это легче читать ???

Код (Text):

1. proc1   WHEN x=0
2.     ELSE proc2 WHEN x=1
3.     ELSE proc3 WHEN x=2

Вопрос без намека на издевательство: а на чем вы писали, коли так привыкли к этому изврату ?

 

Хорошо, когда только x:=10, а если чуть более сложное? Что, любую вложенность больше двух-трех операций выполнять в виде отдельной процедуры? Даже если и удастся избежать накладных расходов вызова и передачи параметров за счет инлайн-функций/процедур, то анализировать такой код заколебешься - для большинства таких микропоследовательностей не удастся придумать само за себя говорящее название процедуры/функции, придется отвлекаться на внутренности таких микропроцедур - стек в голове переполнится (у нормального человека величина стека на-все-про-все - 7+/-2 недетализированных сущностей).

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

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

А может быть такой велосипед уже изобретен, знает кто-нибудь?

 

Dmitry_Milk

Ну мне в особо запущенных случаях помогает стандартная Visual Studio c возможностью Outline. т.е. скрываешь части кода которые тебе не важны/формируешь более - менее удобную структуру для навигации. Не очень удобно, но гораздо легче просматривать километровый кодес состоящий из кучи вложенных if 'ов.

З.Ы. Кстати где-то видел нечто "навигатор по коду" который отображает в ListBox'е слева как раз вложенные условия с комментариями к ним, циклы и.т.п. Мне не показался удобным, не люблю тыцкать крысой по всему монитору, а работать при помощи кейборда с ним дико неудобно, посему не запоминал. Но почему - то кажется что много их...

 

Ну это у вас VisualStudio. А у кого-то из возможного инструментария - всего лишь vi.

 

SadKo
Одна из причин по которой так и не перейду на Linux - отсутствие чего-то что вообще можно было бы назвать IDE ( Eclipse не предлагать ! ), нормального отладчика и мегатонны такого кода... грхм... о котором в этом топике и идет речь.

З.Ы. Хотя как утверждают некоторые товарищи из Vi можно слепить все что хочешь. Увы, я не слепил

 

Wizard109
QtCreator для плюсов очень неплох.