Почему так много кода выглядит именно так? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Но не означает ли это, что если они просят помочь с синтаксисом или логикой, то код не будет " ... синтаксически и логически правильным;"?
Да, вы правы. Но в контексте обсуждения более (или менее) эффективных стилей/практик кодирования, наиболее важным аспектом является то, чтобы код был синтаксически и логически правильным, независимо от используемого стиля кодирования. Думаю, по-другому можно сказать, что стиль должен уступить место синтаксически и логически правильному коду - основной вопрос не в том, хорошо ли выглядит код и легко ли он читается, а в том, является ли он синтаксически и логически правильным для выполнения задачи, для которой он написан. :)
Я также согласен насчет // комментариев. Никогда не может быть слишком много // комментариев, как для того, чтобы освежить в памяти первоначального программиста особенности различных частей кода, так и для того, чтобы помочь другим понять код после завершения/реализации.
Да, вы правы. Но в контексте обсуждения более (или менее) эффективных стилей/практик кодирования, наиболее важным аспектом является то, чтобы код был синтаксически и логически правильным, независимо от используемого стиля кодирования. Думаю, по-другому можно сказать, что стиль должен уступить место синтаксически и логически правильному коду - основной вопрос не в том, хорошо ли выглядит код и легко ли он читается, а в том, является ли он синтаксически и логически правильным для выполнения задачи, для которой он написан. :)
Хорошо, я понял, что вы хотите сказать... красиво представленный код не имеет смысла, если он не работает... но, возможно, его легче исправить?
Я думаю, что большинство стилей кодирования позволяют обеспечить столько читабельности, сколько хочет или требует кодер, я закрываю свой код, когда он закончен и работает, но его легко открыть обратно с несколькими пробелами в строках, если мне нужно поделиться им или обсудить его. Я думаю, что формат кодирования должен поддерживать легкую идентификацию отсутствующей скобки, а также легкую идентификацию пар if else, когда есть сложное дерево if else с несколькими ветвями. Я никогда не принимал стиль K&R, поэтому хотел бы посмотреть, как это делают кодеры в стиле K&R.
Я закрываю свой код, когда он закончен и работает, но его легко открыть обратно с несколькими пробелами в строках, если мне нужно поделиться им или обсудить его.
Зачем вообще его закрывать? Я действительно не понимаю смысла в скомканном коде. Если вам нужно открыть его, чтобы поделиться или обсудить, что это значит?
Я думаю, что формат кодирования должен поддерживать легкую идентификацию отсутствующей скобки и легкую идентификацию пар if else, когда есть сложное дерево if else с несколькими ветвями. Я никогда не принимал стиль K&R, поэтому хотел бы посмотреть, как это делают кодеры в стиле K&R.
Для стиля K&R нижняя скобка выравнивается с условием согласования. Лично я использую
1. Последовательные отступы
2. Для отдельных утверждений либо выделение скобками и отступы, либо они следуют за условием без скобок.
3. Используйте приличный редактор для программистов, который поддерживает скобки.
Соответствие скобок не является проблемой - большая часть ядра linux написана в этом стиле, и это стандарт Java. Хотя я вижу привлекательность стиля Allman, поскольку в стиле K&R я бы часто вставлял дополнительную пустую строку после условия, чтобы разгрузить код. Возможно, я обратился в другую веру :)
Зачем вообще его закрывать? Я действительно не понимаю смысла в скомканном коде. Если вам нужно открыть его, чтобы поделиться/обсудить, что это означает?
Для стиля K&R нижняя скоба выравнивается в соответствии с условиями. Лично я использую
1. Последовательные отступы
2. Для отдельных утверждений либо выделение скобками и отступы, либо они следуют за условием без скобок.
3. Используйте приличный редактор для программистов, который поддерживает скобки.
Соответствие скобок не является проблемой - большая часть ядра linux написана в этом стиле, и это стандарт Java. Хотя я вижу привлекательность стиля Allman, поскольку в стиле K&R я бы часто вставлял дополнительную пустую строку после условия, чтобы разгрузить код. Возможно, я обратился в другую веру :)
Я просто закрываю его, чтобы он занимал меньше места на экране. Мне нравится видеть одновременно столько, сколько может поместиться на экране. Мне не нужна функция сопоставления скобок, я форматирую его так, что если я помещаю курсор за скобкой и провожу его вертикально вверх по строкам с помощью клавиши со стрелкой, когда он касается другой скобки, она становится ее парой. Если я помещаю его за else и делаю то же самое, когда он касается if, это и есть пара if else.
В этом разделе кода легко увидеть, что третья else парна первой if, вторая else парна второй if, первая else парна третьей if, потому что скобка(и) за каждой else выстраивается вертикально за соответствующей скобкой if. Точно так же легко увидеть, какие if не имеют else, потому что каждая скобка if выстраивается вертикально с соответствующей закрывающей скобкой в кластере за else. Я не предлагаю всем остальным оформлять код таким образом только потому, что мне это нравится, но для меня это компактно и логично.
Я не могу ответить на этот вопрос для каждого кодера, использующего k&r. Честно говоря, чем больше я смотрю на ваш формат, тем больше он мне нравится. Если бы я принял стиль Оллмана, я бы определенно увидел себя использующим вашу модифицированную версию. Скобки выстраиваются друг под другом, что избавляет от открывающих и закрывающих скобок, занимающих целую строку. Вы можете провести курсором по i после if и найти пропущенные скобки, не беспокоясь о соглашениях о табуляции/отступах, компактный режим {вижу большинство ваших кодов на экране}. Так что да, это довольно круто, просто на первый взгляд, поскольку я к этому не привык, это кажется запутанным. И в этом суть вопроса.
Мне кажется, что многие американские кодеры используют стиль [KnR & Allman], в то время как стиль Whitesmiths кажется популярным среди европейцев. Whitesmith также является стилем по умолчанию для Mt4. Нет ничего плохого в любом из этих стилей, просто когда я помогаю кому-то, мне приходится постоянно напоминать себе, чтобы я игнорировал свой стиль K&R и думал больше о Whitesmith. Или использовать форматтер кода.
Почему кто-то хочет писать "сложные деревья if else" - для меня загадка. Когда кто-то оставляет все белое_пространство и форматирование внутри сложного if_nest, это выглядит так, как будто он пытается создать змею | спагетти | зигзаг по всей странице. Первый if начинается на строке 1 и заканчивается на строке 300, примерно 150 или %50 из этих строк занимают скобки. Вместо "сложных деревьев if else" почему бы просто не создать функцию. Тогда пусть строка_1 действительно заканчивается на строке_1 с if( false ){ return; }.
Спасибо ubzen Я рад, что кому-то нравится мой формат lol. Я часто использую if else, возможно потому, что когда я только начинал кодить, кто-то сказал мне, что if else делает быстрый код, и я взял за привычку делать это именно так.
Спасибо ubzen Я рад, что кому-то нравится мой формат lol. Я часто использую if else, возможно потому, что когда я только начинал кодить, кто-то сказал мне, что if else делает быстрый код, и я взял за привычку делать это таким образом.
Ничего личного
Именно в такие моменты было бы хорошо иметь официальный стандарт, по которому все работают... ...тогда бы мы все делали одно и то же, и нам всем нравился бы ваш код. И прежде чем вы спросите, нет, я буду придерживаться своего стиля Whitesmiths... по крайней мере, я знаю, как его теперь называть, спасибо ubzen.