Холивар темы: Может ли быть спагетти-код не на основе goto?

	Комментарий модератора
	Холивар вынесенный из темы Может ли быть спагетти-код не на основе goto?

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

Например совет про разбивку метода на несколько подметодов не имеет особого смысла если это не что-то повторяемое, как раньше говорили - функция. На читаемость это абсолютно никак не влияет, скорее наоборот, потому что вы или читаете последовательно действия или прыгаете от метода к методу. Ограничение метода какими-то строками или экранами это вообще ересь. Метод должен быть ровно такой какой он и должен быть, лично вы вообще на это никак не повлияете, то что вы его расфигачите на 100500 подметодов абсолютно никак не повлияет ни на скорость ни на его читаемость.
Лично сам я люблю сокращать текст кода, писать его по возможности плотнее, но не для читаемости (читаемость как раз ухудшается). Просто я люблю плотный код и делаю я это только тогда, когда работа над методом закончена и что-то исправлять я не планирую.

Как бы всё красиво не звучало, но вы нигде не найдёте единого мнения о том как же именно лучше всего оформлять код. Я иногда вставляю код с этого форума от "великих знатоков ООП" на других ресурсах и этот код обсирают ровно так же, как мой код здесь. Так что угодить всем-всем-всем вы всё равно не сможете. Но можно конечно выбрать для себя например оформление MSDN и работать строго в этом векторе, хотя вам часто так же будут говорить про индусский код, о котором вы и пишете в этой теме.

goto - это не оператор говна, это такой же инструмент как if или for, главное тут уместность его применения. У меня изредка он бывает, в основном для выхода из вложенных циклов или когда сильно проще просто воткнуть goto на время разработки, не вижу как именно goto повлияет на читаемость, ведь вызов любой функции это точно такой же goto (если возвращаться к Бейсику, то это GOSUB), и вам тут же в этой теме совершенно нормально пишут что читаемость кода с кучей методов вдруг становится лучше, непонятно почему вызов метода это хорошо а переход по goto - это уже плохо. И в любом случае в ассемблере все ветвления так или иначе сделаны через goto, которых заметно больше, так как там скорее конструкции (IF условие GOTO). Любая итерация цикла это goto, просто не явный.

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

0

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

Считаю, что не нужно путать построение итогового машинного кода с написанием "человеческого", т.е. который будет понятен не только самому писателю и его 'машине', но и другим людям. Именно для этого и были придуманы ЯП как таковые, и в последствии к ним различные подходы, в виде ООП.

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

Писать "нормальный" код в машинном стиле - уподобляться процессору CPU - мало кто захочет скакать по строкам в поисках нужного.
Диалоги/споры людей с разной идеологией написания кода - вряд ли стоит воспринимать в серьез.

belalugoci, пример со switch не понял вообще - что вы хотели этим показать?

1

Сообщение от Wolfdp Окей, возьмём что-то практическое

сферический конь в вакууме

Сообщение от Wolfdp А теперь вопрос, насколько сложнее записать так?

не понял причем тут сложнее или нет, или вы сравниваете с чем-то что было записано хуже? в общем мне сравнить не с чем, но прокомментирую что я вижу в вашем коде:

Сообщение от Wolfdp var host = HostInitiator.Create(args);

создается объект класса, котором передаются аргументы командной строки

Сообщение от Wolfdp host.Run();

вызывается метод созданного класса

Сообщение от Wolfdp var builder = new HostBuilder();

при создании объекта срабатывает конструктор класса, где создается еще что-то

Сообщение от Wolfdp builder.Configuration(args);

в это что-то опять передаются аргументы

Сообщение от Wolfdp builder.Init(args);

и опять

Сообщение от Wolfdp var host = builder.Build();

и опять что-то создаётся

Сообщение от Wolfdp return host;

и это что-то возращается

Сообщение от Wolfdp builder.ConfigurationDB();

что-то вызывается

Сообщение от Wolfdp builder.ConfigurationNotification(args);

еще что-то вызывается

Сообщение от Wolfdp builder.InitModule1(args);

опять что-то вызывается

Сообщение от Wolfdp builder.InitModule2();

и еще

Сообщение от Wolfdp builder.InitModule3();

и еще

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

Сообщение от Wolfdp Теперь мы можем покрыть Sort тестом, т.к. internal внезапно можно сделать публичным для сторонней библиотеки (а тесты по сути и являются обычной сторонней либой).

ну если у вас стояла такая задача, то почему бы и нет, не помню чтобы я вам запрещал так делать, НО!!!! вы мне лично запрещаете делать так как нужно мне, чувствуете разницу?

Сообщение от Wolfdp Я писал прям про чистый код скажем на 1к строк

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

Сообщение от Wolfdp в котом сначала один цикл, потом второй, пучёк методов и снова цикл

ну вот я вам расписал чтение вашего кода, там нет циклов и методов не особо много, но читать там нечего, набор букв. Пардон, но я такую фигню не пишу никогда. И я не пишу программ которые когда-то где-то возможно может быть будут кем-то масштабироваться меняться или что-то там еще. Я решаю задачу, по ТЗ. Если задача вывести на экран температуру ЦПУ, то я это делаю. Если задача написать класс для повторного использования который будет отдавать информацию о состоянии ПК - я это и пишу. Я не пишу методы ради методов, ради какого-то там оформления или ради какой-тот вселенской красоты и успокоения перфекционистов-онанистов. Программирование - это автоматизации процесса, в одном случае она подразумевает неоднократное примнение или расширение функционала, в другом - нет.

Сообщение от Wolfdp И вот копаешься скажем в последнем цикле и не понимаешь -- это локальная переменная для цикла, или для всего метода?

это не связано с размером самого метода, это такое же разумное использование ЯП как в любом другом случае, вам никто не запрещает использовать какую-то переменную многократно на протяжении всего метода, например i, j или x, y, но так же никто не запрещает разделить код например фигурными скобками выделив какую-то часть. Мне кажется вы в данном случае пытаетесь какие-то свои комплексы и страхи запихать в разговор.

Сообщение от Wolfdp Листаешь вверх, видишь её объявление в самом начале. Листаешь вниз, смотришь где она ещё используется

если переменная меняется в коде, а вы этот код читаете, то вы и знаете где она объявлена, где изменена и где используется. И даже если она используется по тексту ниже, то видя "A=" вы чётко видите что её содержимое перезаписано, какой смысл в этом месте например писать int B= если можно написать A= - что это изменит?

Сообщение от Wolfdp Частично это можно "пофиксить" скобками, как предлагал Элд Хасп, но всё равно уныло.

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

Сообщение от wizard41 belalugoci, пример со switch не понял вообще - что вы хотели этим показать?

что свич в C# туповато сделан.

0

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

Как раз для этого и придумали стили оформления кода и принципы проектирования - чтобы люди, которые мыслят по разному, писали код более-менее похоже и легче могли понимать друг друга. Да, нарушение этих принципов не карается уголовным кодексом, поэтому они у разных людей могут отличаться. Тем не менее, опытный программист сможет относительно легко въехать в код написанный даже на языке, на котором никогда не писал. К примеру, мне как-то приходилось разбираться в коде андроид приложения на котлине или в веб-сайте на руби и даже вносить туда доработки. Хотя ни до этого, ни после, я ни с котлином ни с руби вообще не сталкивался. А всё потому, что в целом код был написан по хорошо известным принципам, которые хоть в котлине, хоть в руби - одни и те же. Хотя, детали реализации и синтаксически эти языки очень разные. Если бы эти проекты были написаны как бог на душу положит плюя на все принципы - никаких шансов быстро разобраться в них, и тем более что-то там править, не было бы.

1

Сообщение от belalugoci свич в C# туповато сделан.

Эммм... 20 лет не было с ним проблем, а тут вдруг что-то стало не так... Issue в майкрософт уже отправили - пересмотреть конструкцию?
И по теме: Etyuhibosecyu хочет как раз обратного, а не того что вы советуете..

0

Сообщение от Катафалк Сообщение от belalugoci и вам повезёт если тот кто будет писать код будет всё придумывать так же как вы,... Как раз для этого и придумали стили...

Дополню.

Условно есть две категории разработчиков - если рассматривать крайние случаи.

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

И есть другие разработчики, которые могут только простыни кода ПП писать "для себя". Единственный их аргумент "Я художник, я так вижу". Но по сути они просто по другому не умеют.
И ставить "на одну доску" советы таких "умельцев" с разработчиками первой категории не стоит.
Какой-то Вася Пупкин "Да, нафиг это ООП мне нужно! Херню развели какую-то. Не знал его и знать не собираюсь. У меня вон всё работоет. И хер с ним, что никто, даже я сам, не понимает как оно работает." - такие советы имеют нулевую, если не отрицательную, ценность.

Добавлено через 12 минут

Сообщение от wizard41 Сообщение от belalugoci что свич в C# туповато сделан. Эммм... 20 лет не было с ним проблем, а тут вдруг что-то стало не так... Issue в майкрософт уже отправили - пересмотреть конструкцию?

Если правильно понял belalugoci
Речь о том, что раз break; является обязательной завершающей инструкцией блока case , то почему не считать по умолчанию, что следующий case имеет неявно перед собой break;.
Типа как в void методе. Можно поставить return; но и если не ставить его, то после последней инструкции метода он не явно присутствует.
Здесь я скорее соглашусь с belalugoci.
Хотя глубоко не лез в эту тему и при поверхностном взгляде могу не видеть каких-то подводных камней.

1

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

а какая связь оформления кода и программирования? это вообще никак не связанные вещи.

Сообщение от Катафалк Тем не менее, опытный программист сможет относительно легко въехать в код написанный даже на языке, на котором никогда не писал

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

Сообщение от Катафалк К примеру, мне как-то приходилось разбираться в коде андроид приложения на котлине или в веб-сайте на руби и даже вносить туда доработки

так всё же вы разбирались с реализацией или с синтаксисом, как мне показалось вы в одну кучу сваливаете синтаксис языка, реализацию и принцип оформления кода.
с синтаксисом вроде всё понятно - читаете доки и в голове выстраиваете аналогии, я так читаю код на питоне, си, си++, паскале и т.п.
реализация - а вот тут всё не так однозначно, вот простой ПРИДУМАННЫЙ пример (в реальности всё куда сложнее чаще всего), в авторской реализации входные данные разбиваются на подмассивы по определенным условиям, потом делятся на группы по 16 и прогоняются через функцию, результат складывается в отдельный массив, над которым в финале опять происходят какие-то вычисления. Ну вот вы видите это и дальше что? Это для вас черный ящик, вы в душе не чаете что тут происходит. И как вы это будете дорабатывать? Например у вас во входных данных что-то изменилось и при отправке результата на другой сервер, который вам может только выдать результат- валидно или нет, вам прилетает - не валидно. Доступа к серверу у вас нет, он стоит в калифорнии у какой-то компании. А вы в РФ, на письма вам не отвечают, описания API сервера у вас нет. Дальше что? Ну вот если опыта у вас хватит вы опознаете что это MD5, а если нет?
А принцип оформления кода тут вообще ни при делах.

Сообщение от wizard41 Эммм... 20 лет не было с ним проблем

а вам докладывали? мне кажется проблему я описал достаточно понятно.

Сообщение от wizard41 Issue в майкрософт уже отправили - пересмотреть конструкцию?

несколько раз не конкретно по switch, но реакции не было, поэтому не пишу больше.

Добавлено через 17 минут

Сообщение от Элд Хасп Есть разработчики, которые на практике сталкивались с огромным количеством задач

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

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

Сообщение от Элд Хасп Если правильно понял belalugoci

конкретно мой пример вы поняли частично правильно.
я написал о том, что отсутствие break должно создавать ситуацию без завершения, что логично, иначе зачем тогда этот break вообще нужен. Синтаксис без завершающего break позволит при ветвлении продолжать код с другим условием.
пример, насколько я помню недавно разрешили делать так:
то есть к нескольким условиям применять один код. Из этого же синтаксиса следует логичное продолжение
вместо избыточного
так же нет поддержки явного вызова/перехода из одного условия в другое, хотя бы для default, например так
безусловно можно реализовать городушку и обойти эти ограничения, но тогда мы отделим логику и вынесем её за рамки switch, что для меня кажется нелогичным.

0

Сообщение от belalugoci а какая связь оформления кода и программирования? это вообще никак не связанные вещи.

Т.е. как это? Вы программируете как то по другому, не с помощью кода?

Сообщение от belalugoci только в том случае если он поймёт логику самой реализации, если не сможет понять то это будет просто набор команд на каком-то языке.

Так в том и суть, что логику понять проще, когда она описана с использованием стандартных приёмов и паттернов. Это во первых. А во вторых, понимать логику всей программы часто не нужно. Да для больших проектов это может быть даже и невозможно. Если доработка делается в какой то части функционала, то нужно детально понять логику этой части. И здесь важно, чтобы она была локализована в коде, а не размазана по всему проекту. Поэтому и нужна грамотная архитектура программы. А не лапша на 100500 строк в одном файле, который делает всё.

Сообщение от belalugoci Ну вот если опыта у вас хватит вы опознаете что это MD5, а если нет?

Ну отличный пример говнокода. Если бы в вашем ПРИДУМАННОМ примере ПРИДУМАННЫЙ автор исходного ПРИДУМАННОГО кода назвал функцию что-то вроде generate_md5, то описанной проблемы бы просто не существовало, ибо сразу было бы понятно, что тут происходит.

0

Сообщение от belalugoci то есть к нескольким условиям применять один код. Из этого же синтаксиса следует логичное продолжение

Здесь концепция другая.
Каждый блок кода в case - это как маленькая подпрограмма.
break; - это выход из этой подпрограммы.
Каждый case описывает условия входа в подпрограмму.

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

Я думаю, у вас в этом случае просто "тяга к goto".
case вы воспринимаете как "условные метки".
В коде же логично после выполнения кода одной метки продолжить код выполнять дальше, если даже там есть другие метки. Так почему же с case не сделать так же?

Но как я объяснил - в case заложена совсем другая концепция.
Менять концепции которые лежат в самых основах ЯП всегда сложно. Они же тоже принимаются не на пустом месте и были веские основания почему сделано именно так. Учитывалось всё от основ ОПП, до компиляции в CIL, выполнения в CLR и многое другое.
Чтобы предлагать такие концептуальные изменения надо разбираться во всё этом на уровне общества разработчиков поддерживающих развитие Шарпа.

0

Касательно switch

Сообщение от Элд Хасп Здесь концепция другая. Каждый блок кода в case - это как маленькая подпрограмма. break; - это выход из этой подпрограммы. Каждый case описывает условия входа в подпрограмму.

Мне тоже не нравится реализация данной языковой конструкции и вот почему:
Во первых, оператор назван switch, а не, например, jump. Что подразумевает именно переключение на нужный блок кода, а не переход к какому-то месту кода и последующему выполнению всех блоков вслед за ним в пределах оператора.
Представьте аналогию с электрическим переключателем, где Вы переключаетесь на напряжение 12В, а после того как 12В подано подаётся 24В, 36В и т.д. пока нагрузка не сделает пшик или бабах. Вы же не ожидаете такого от переключателя как бы он ни был реализован?
Во вторых, в данном ЯП есть явные границы блока кода, т.е. скобки {}. Ведь в конце любого метода ни до, ни после скобок мы не ставим break. Что мешало реализовать оператор с их применением? Например чем был бы плох такой синтаксис?
И да, спорить не собираюсь, к текущему синтаксису привык и есть понимание, что никто менять то, к чему люди привыкли, не будет.

Сообщение от Элд Хасп Они же тоже принимаются не на пустом месте и были веские основания почему сделано именно так.

Ой, да ладно Вам, на заре появления ЯП там скорее всего сделали через тот же Goto, так как было проще, а со временем все привыкли и менять уже бессмысленно.

0

Сообщение от Катафалк Т.е. как это? Вы программируете как то по другому, не с помощью кода?

Программирование — это процесс создания программного обеспечения (ПО) путём написания, тестирования и отладки кода на одном из языков программирования.
Оформление кода (или стиль кодирования) — это набор правил и соглашений о том, как писать и структурировать код, чтобы он был:
- Читаемым (понятным для других разработчиков и вас в будущем),
- Единообразным (одинаковым стиль в рамках проекта),
- Поддерживаемым (легким для изменений и отладки).
Разницу вам объяснять?

Сообщение от Катафалк Так в том и суть, что логику понять проще, когда она описана с использованием стандартных приёмов и паттернов

Нет, потому что понимание логики никак не связано с оформлением. Читаемость команд или кода - возможно. Сложность чтения кода - вероятно, но понимание логики - это совсем про другое.

Сообщение от Катафалк А во вторых, понимать логику всей программы часто не нужно

а часто - нужно

Сообщение от Катафалк Поэтому и нужна грамотная архитектура программы

это слишком субъективное определение

Сообщение от Катафалк А не лапша на 100500 строк в одном файле, который делает всё.

вероятно это скорее зависит от проекта и его масштаба

Сообщение от Катафалк Ну отличный пример говнокода. Если бы в вашем ПРИДУМАННОМ примере ПРИДУМАННЫЙ автор исходного ПРИДУМАННОГО кода назвал функцию что-то вроде generate_md5, то описанной проблемы бы просто не существовало, ибо сразу было бы понятно, что тут происходит.

XD обсуждать пример вместо самой проблемы это так мило

Сообщение от Элд Хасп Здесь концепция другая

какая разница какая там концепция если сделано дебильно

Сообщение от Элд Хасп Иметь несколько условий входа для подпрограммы - это норм. Но вот неявный переход из одной подпрограммы в другую - это, мягко говоря, неоднозначно.

switch - это конструкция из if-ов (аналогия for/while), if-ы бывают вложенные, со сложными условиями. Не вижу проблемы сложность одного поддерживать в другом, для if-ов вы же про неоднозначность ничего не пишете, значит не в этом дело.

Сообщение от Элд Хасп Я думаю, у вас в этом случае просто "тяга к goto".

нет, я просто хочу упростить код

Сообщение от Элд Хасп case вы воспринимаете как "условные метки"

любой switch можно записать в виде if/goto или просто if, тут как вам больше нравится, например мой пример выше можно записать так:
или без goto
и если рассматривать последнюю конструкцию, то там действительно сложно перейти куда-то внутрь другого условия без goto. А для первого варианта всё органично и последовательно.

Сообщение от Элд Хасп В коде же логично после выполнения кода одной метки продолжить код выполнять дальше, если даже там есть другие метки

не совсем понимаю причем здесь логика, это вопрос исключительно гибкости конструкции ЯП, на ассемблере в любом случае всё будет на JMP/JNE/JZ и т.д.

Сообщение от Элд Хасп Менять концепции которые лежат в самых основах ЯП всегда сложно. Они же тоже принимаются не на пустом месте и были веские основания почему сделано именно так. Учитывалось всё от основ ОПП, до компиляции в CIL, выполнения в CLR и многое другое. Чтобы предлагать такие концептуальные изменения надо разбираться во всё этом на уровне общества разработчиков поддерживающих развитие Шарпа.

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

Добавлено через 2 минуты

Сообщение от Элд Хасп в новом его не будет и следующий case будет означать и неявное наличие break;

это исключит возможность появления тех самых фич о которых пишу я.

Сообщение от Элд Хасп Может стоит официально предложить такие изменения

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

0

Сообщение от belalugoci switch - это конструкция из if-ов (аналогия for/while)

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

0

Сообщение от Элд Хасп Здесь концепция другая. Каждый блок кода в case - это как маленькая подпрограмма. break; - это выход из этой подпрограммы.

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

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

1

Сообщение от golosalex согласен с этим. в том же СИ есть грабли, которые позволяют провалиться из одного case в другой, если нет break

не более чем вкусовщина

0

Сообщение от belalugoci Разницу вам объяснять?

Разницу между чем и чем?

Сообщение от belalugoci Нет, потому что понимание логики никак не связано с оформлением. Читаемость команд или кода - возможно. Сложность чтения кода - вероятно, но понимание логики - это совсем про другое.

А по-моему, про то же самое. Вернее, это вещи очень связанные. Ибо если код написан через одно место, то понять его логику будет сложно, даже если там простой hello world. И наоборот, если там все написано в едином стиле, с разумной декомпозицией, неймингом и т.д., то и понимать логику будет легче.

Сообщение от belalugoci это слишком субъективное определение

Субъективное - это да. Но не то, чтобы слишком. Да, в каких то моментах мнения разных разработчиков могут не сойтись. Но если взять, например, код ТС и показать его 100 разработчикам, то скорее всего 95 из них скажут, что это нечитаемая лапша, которую нужно отрефакторить. Что мы в этой теме и видим. Пока что тут не отметился никто, кто бы похвалил его код.

Сообщение от belalugoci XD обсуждать пример вместо самой проблемы это так мило

И в чём же ваша проблема? И вашего примера я так понял, что именно в том, чтобы разобраться, что делает тот или иной код. Решение этой проблемы известно - писать с использованием общепринятых паттернов и принципов. Но вам это решение почему-то не нравится. Почему и какие ещё решения вы хотите предложить? Если я неправильно понял вашу проблему, то прошу поправить.

0

Сообщение от Катафалк Разницу между чем и чем?

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

Сообщение от Катафалк А по-моему, про то же самое. Вернее, это вещи очень связанные

Нет, дольше, легче, сложнее, проще - вполне вероятно на таком уровне, но само понимание с этим не связано.

Сообщение от Катафалк Ибо если код написан через одно место, то понять его логику будет сложно, даже если там простой hello world

нет, в данном случае вы озвучиваете то, как вам удобно, а не то - можно понять или нельзя.

Сообщение от Катафалк И наоборот, если там все написано в едином стиле, с разумной декомпозицией, неймингом и т.д., то и понимать логику будет легче.

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

Сообщение от Катафалк Субъективное - это да. Но не то, чтобы слишком. Да, в каких то моментах мнения разных разработчиков могут не сойтись. Но если взять, например, код ТС и показать его 100 разработчикам, то скорее всего 95 из них скажут, что это нечитаемая лапша, которую нужно отрефакторить. Что мы в этой теме и видим. Пока что тут не отметился никто, кто бы похвалил его код.

тут я соглашусь

Сообщение от Катафалк И в чём же ваша проблема? И вашего примера я так понял, что именно в том, чтобы разобраться, что делает тот или иной код. Решение этой проблемы известно - писать с использованием общепринятых паттернов и принципов. Но вам это решение почему-то не нравится. Почему и какие ещё решения вы хотите предложить? Если я неправильно понял вашу проблему, то прошу поправить.

я всё равно не могу понять как принцип оформления кода поможет мне понять что именно делает код? Почему автор кода написал int a=1 и почему b=3? зачем создал массив и для чего то да сё? Я часто переписываю реализации тех или иных алгоритмов под себя, потому что авторская реализация мне непонятна абсолютно, соответственно я не могу её изменять, тюнинговать и т.п. То есть я знаю что там алгоритм Х, но как оно работает у автора я не понимаю, соответственно с оформлением кода это вообще не связано. И реализаций одного и того же алгоритма могут быть десятки.

0

belalugoci, заметили как много несогласных с вашей позицией ?
А еще , я заглянул в профиль и увидел в интересах - MOS 6502 ATARI , предположу , что Вы больше склонны к системному программированию , небольшие подпрограммки , у системщиков вообще плохо обычно с ООП и энтерпрайз подходами , ибо задачи другого масштаба.

1

Сообщение от belalugoci я всё равно не могу понять как принцип оформления кода поможет мне понять что именно делает код? Почему автор кода написал int a=1 и почему b=3? зачем создал массив и для чего то да сё? Я часто переписываю реализации тех или иных алгоритмов под себя, потому что авторская реализация мне непонятна абсолютно, соответственно я не могу её изменять, тюнинговать и т.п. То есть я знаю что там алгоритм Х, но как оно работает у автора я не понимаю, соответственно с оформлением кода это вообще не связано. И реализаций одного и того же алгоритма могут быть десятки.

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

0

Сообщение от sau заметили как много несогласных с вашей позицией ?

с какой? что красиво оформляя код можно понять то чему не учился?

Сообщение от sau Вы больше склонны к системному программированию

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

Сообщение от sau у системщиков вообще плохо обычно с ООП и энтерпрайз подходами

дело в том что форум и соответственно обсуждаемые темы не имеют никакой связи с профессиональной средой и применением, отсюда мне непонятен в принципе настрой у некоторых пользователей. Большинство задач в темах находятся на уровне "Hello World!" т там при всём желании абсолютно бесполезно постоянно вспоминать про ООП и энтерпрайз подходы.

Сообщение от sau ибо задачи другого масштаба

так может вы все форумом ошиблись ) ну или как минимум разделом?

Добавлено через 7 минут

Сообщение от Катафалк к примеру об алгоритмах сжатия данных, а пришли их дорабатывать

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

Сообщение от Катафалк Кодстайл и паттерны это не волшебная пилюля, заменяющая образование

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

0

Сообщение от belalugoci так может вы все форумом ошиблись ) ну или как минимум разделом?

Да нет, это кажись вы тут постоянно забегаете и наводите шороху.

Лично опрос не проводил, но что-то мне подсказывает что все несогласные с вами либо работают программистами и пишут программы на .net, либо очень плотно изучали эту clr. Вспоминая как вы постоянно заходя в ту или иную тему начинаете доказывать ненужность ООП, git, оформление кода -- складывается впечатление что вам интересно именно идти против системы, а не узнавать что-то новое и учиться.

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

5

Сообщение от belalugoci Надеюсь вы не утверждаете что выходя из вуза вы знаете всё-всё-всё?

Что? Как вы вообще из моих слов к такому выводу умудрились прийти?

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

Это не правда. Ещё раз перечитайте что я написал. При выполнении определённых условий - помогает. Повторю:

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

Сообщение от belalugoci Ну и приходить что-то кодить где у вас нет никакого образования так же странно как и утверждать, что вы без знаний способны всё понять.

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

0