Существует ли язык, который поощряет хорошие методы кодирования?
В то время как я люблю PHP, я нахожу, что его самая большая слабость - то, что он позволяет, и даже почти поощряет программистов писать плохой код.
Существует ли язык, который поощряет хорошие практики программирования? Или, более конкретно, связанный с сетью язык, который поощряет хорошие методы.
Я интересуюсь языками, кто имеет или установленную цель ободрительного хорошего программирования или разработан таким способом как для поощрения хорошего программирования.
24 ответа
Ну, это зависит от того, что вы считаете веб-языком. Smalltalk определенно поощряет лучшие практики, и на нем даже написана безумная веб-среда ( Seaside ). Это совсем другое, и ты все еще можешь делать плохие вещи. Вас просто поощряют поступать иначе.
Эйфель очень популярен - Дизайн по контракту. Это изящное организационное требование, которое поощряет тестирование и утверждения повсюду.
Python великолепен, но на самом деле это не способствует хорошему опыту. Что ж, если отступы - лучшая практика, то Python определенно применяет их.
Другие языки на самом деле не поощряют вас делать плохие вещи, как это делает PHP. Вы также можете написать отличный (и правильный) код на PHP. Люди часто забывают, что в интерпретаторе можно отключить большую часть неприятностей (глобальные переменные, косые черты и т. Д.). Вам не нужно прыгать с корабля только потому, что PHP просто соблазняет вас на темную сторону.
Практика кодирования не зависит от языка. Вы можете практически испортить исходный код на любом языке, и то, что является хорошей практикой, является субъективным.
Например, в C # на уровне функции вы можете объявить любую переменную с помощью var, и компилятор будет обеспечивать безопасность типов, однако многие люди не люблю var и думаю, что он усложняет расшифровку кода. Мне лично нравится var, особенно когда тип упоминается справа:
Например,
var firstName = new string ();
для меня лучше, чем ...
string firstName = new string () ;
... потому что зачем мне произносить строку firstName, если я знаю, что это строка, основанная на правостороннем создании экземпляра? Конечно, это опять же субъективно.
Стандарты и использование инструментов анализа кода в сочетании с обзорами кода действительно могут иметь значение. http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Да, Python. Многие из целей его дизайна преследуют заявленную цель поощрения хороших практик программирования. Прочтите руководство по Python и Zen of Python (введите "import this" в командной строке Python).
C # несомненно ... хорошая база и постоянно совершенствуется.
для ясности Вы можете писать плохой код на любом языке
в любом случае C # действительно хорош для следования хорошим методам программирования
Haskell.
- Он заставляет вас писать чистый код отдельно
- Он использует синтаксис табуляции, заставляя пробелы
- Модульная система позволяет легко организовать код
Я бы выбросил C # там. Он поощряет использование хороших методов, читаемый код и предоставляет инструменты для обеспечения того, чтобы ваши комментарии были полезными и целевыми.
Они также предоставляют инструменты статического анализа "из коробки", чтобы убедиться, что код хорош.
Если я правильно читаю вопрос, то вы ищете язык, в котором "легкая" вещь и "лучшие практики" тесно связаны.
Если это так, то каковы «лучшие практики»? Начнем с этого :)
И как немного странное предложение, могу я предложить LISP или схему?
Что касается написания «плохого» кода ... вы должны научиться этого не делать;)
Что касается написания «хорошо стилизованного» кода - возьмите копию Visual Studio, Плагин ReSharper и StyleCop. Intellisense и автоформатирование (Visual Studio) помогут вам красиво разложить вещи, плагин ReSharper реструктурирует ваш код в «предпочтительную» структуру, а StyleCop поможет вам следовать стандарту.
Это довольно субъективно, но я бы сказал Python. Важна удобочитаемость, и есть только один способ сделать работу с языком очень простой.
Рамки также могут укреплять передовой опыт. Фреймворк Python Django основан на шаблоне «MTV» и поддается очень дружелюбному коду.
Вы можете применять хорошие методы на любом языке.
Однако вы можете применять плохие методы и на любом языке.
PASCAL - один из языков программирования, который поощряет хорошие методы программирования
Я думаю, что Python предлагает несколько идей для правильного кодирования. По крайней мере, программы вынуждены выглядеть одинаково.
Но не забывайте, что Ларри Уолл сказал:
Настоящие программисты могут писать ассемблерный код на любом языке.
Вам лучше подумать о создании соглашения о стилях кодирования .
Краткий ответ? Нет. Но в вопросе используются идеи на английском языке, которые не поддаются компьютерному программированию. Что значит «поощрять»? Что такое «хорошая практика программирования»? Подсветка синтаксиса и автоматический отступ? Конечно, это под силу любому языку. Предупреждения в стиле линта? Не очень сложно. Стиль полицейского? Что ж, нам пришлось бы допустить C, если бы это было критерием.
Хорошая практика программирования естественно возникает из хорошего дизайна. Умным программистам довольно сложно написать плохой код на любом языке, если дизайн чистый и простой. И наоборот, плохая практика следует из плохого дизайна. Сложность заключается в том, чтобы понять, где дизайн перестает быть хорошим и становится плохим. Это вопрос №1 в разработке программного обеспечения, и, к сожалению, нет серебряной пули. Эти прекрасные шаблоны дизайна начинают выглядеть ужасно некрасиво, когда вы внедряете несколько из них в свое приложение.
? Подсветка синтаксиса и автоматический отступ? Конечно, это под силу любому языку. Предупреждения в стиле линта? Не очень сложно. Стиль полицейского? Что ж, нам пришлось бы допустить C, если бы это было критерием.Хорошая практика программирования естественно возникает из хорошего дизайна. Умным программистам довольно сложно написать плохой код на любом языке, если дизайн чистый и простой. И наоборот, плохая практика следует из плохого дизайна. Сложность заключается в том, чтобы понять, где дизайн перестает быть хорошим и становится плохим. Это вопрос №1 в разработке программного обеспечения, и, к сожалению, нет серебряной пули. Эти прекрасные шаблоны дизайна начинают выглядеть ужасно некрасиво, когда вы внедряете несколько из них в свое приложение.
? Подсветка синтаксиса и автоматический отступ? Конечно, это под силу любому языку. Предупреждения в стиле линта? Не очень сложно. Стиль полицейского? Что ж, нам пришлось бы допустить C, если бы это было критерием.Хорошая практика программирования естественно возникает из хорошего дизайна. Умным программистам довольно сложно написать плохой код на любом языке, если дизайн чистый и простой. И наоборот, плохая практика следует из плохого дизайна. Сложность заключается в том, чтобы понять, где дизайн перестает быть хорошим и становится плохим. Это вопрос №1 в разработке программного обеспечения, и, к сожалению, нет серебряной пули. Эти прекрасные шаблоны дизайна начинают выглядеть ужасно некрасиво, когда вы внедряете несколько из них в свое приложение.
d должен был признать C, если это было критерием.Хорошая практика программирования естественно возникает из хорошего дизайна. Умным программистам довольно сложно написать плохой код на любом языке, если дизайн чистый и простой. И наоборот, плохая практика следует из плохого дизайна. Сложность заключается в том, чтобы понять, где дизайн перестает быть хорошим и становится плохим. Это вопрос №1 в разработке программного обеспечения, и, к сожалению, нет серебряной пули. Эти прекрасные шаблоны дизайна начинают выглядеть ужасно некрасиво, когда вы внедряете несколько из них в свое приложение.
d должен был признать C, если это было критерием.Хорошая практика программирования естественно возникает из хорошего дизайна. Умным программистам довольно сложно написать плохой код на любом языке, если дизайн чистый и простой. И наоборот, плохая практика следует из плохого дизайна. Сложность заключается в том, чтобы понять, где дизайн перестает быть хорошим и становится плохим. Это вопрос №1 в разработке программного обеспечения, и, к сожалению, нет серебряной пули. Эти прекрасные шаблоны дизайна начинают выглядеть ужасно некрасиво, когда вы внедряете несколько из них в свое приложение.
Сложность заключается в том, чтобы понять, где дизайн перестает быть хорошим и становится плохим. Это вопрос №1 в разработке программного обеспечения, и, к сожалению, нет серебряной пули. Эти прекрасные шаблоны дизайна начинают выглядеть ужасно некрасиво, когда вы внедряете несколько из них в свое приложение. Сложность заключается в том, чтобы понять, где дизайн перестает быть хорошим и становится плохим. Это вопрос №1 в разработке программного обеспечения, и, к сожалению, нет серебряной пули. Эти прекрасные шаблоны дизайна начинают выглядеть ужасно некрасиво, когда вы внедряете несколько из них в свое приложение.Язык Boo по тем же причинам, что и Python.
Может быть, я немного предвзят ...?
Я думаю, что аспект языка/рамки, о котором нечасто говорят, это сообщество вокруг него.
Я думаю, что Rails делает большую работу, поощряя лучшие практики не только в самой технологии - которая очень сильно сфокусирована на хороших практиках, например, создание юнит-тестов при генерации строительных лесов, но и в сообществе, которое поощряет лучшие практики и т.д.
.Вы, возможно, захотите прочитать книгу о море , чтобы получить некоторые идеи о том, как DRY веб-приложений. Устранение шаблонов, последующее построение DSL для html и javascript фреймворков (a.o. jQuery, Scriptaculous, Prototype, RaphaelJs) и даже css (Phantasia, не в базовом дистрибутиве), комбинация с OODB для persistence (Gemstone) дает много , почему текущее состояние php, java, ruby или c# намного хуже ?
.Ассемблер соответствует законопроекту "языка, где плохие вещи либо активно отбивают охоту, либо просто прямо-таки трудны" - сегрегация вашей программы во время выполнения скорее отбивает охоту, а написание плохо структурированного программного обеспечения в сети на ассемблере было бы прямо-таки трудным.
Почему ты спрашиваешь? Похоже, что вопрос часто возникает после того, как я разобрался с каким-то гадким кодовым волосатым шариком. Я часами разбираю спагетти-логику, которая проходит через 6 уровней подпрограммы. И наконец, отслеживаю ошибку в ниггелях. И моя первая мысль - почему это не может быть проще?
Код написан для компьютера, а не для людей. Он оптимизирован для машины. Машины требуют точных инструкций. При такой степени детализации сложность любой кодовой базы быстро возрастает. И именно эта сложность обычно движет этим вопросом.
Языки программирования не предназначены для управления сложностью. Помочь в этом могут инструменты программирования . То, как Вы пишете свой код, имеет гораздо большее значение, чем , на каком языке Вы пишете свой код.
Взгляните на грамотное программирование . Оно контролирует сложность через организацию. Лично мне нравится визуальная структура, предоставляемая редактором Leo.
.Серебряной пули нет. Технология не сделает из вас лучшего программиста
.Это слишком субъективно. Если под "хорошей практикой программирования" вы подразумеваете последовательный отпечаток, то конечно, Python работает на это. Но отступ - это то, чему большинство программистов учится при первом написании программы. Я думаю, что хорошее программирование выходит далеко за рамки этого.
С годами идея о том, что такое хорошая практика программирования, изменилась. Python, кроме отступа, на самом деле не преуспевает ни в одной из категорий. Это не самый объектно-ориентированный язык вокруг, и он (пока) не предлагает полной поддержки для функционального программирования.
Вот несколько возможных определений хорошей практики программирования, и репрезентативный язык для каждого:
- Чисто объектно-ориентированный дизайн:. SmallTalk был первым настоящим OO-языком, и в некотором роде все еще чистейшим. Буквально все является классом.
- Прагматичный объектно-ориентированный дизайн:. Java, при всей своей недоброжелательности, стала огромным шагом вперед с точки зрения поощрения хорошей практики программирования. Она сильно типизирована, почти все является классом, и требует в некоторой степени самостоятельного документирования дизайна класса (явным перечислением брошенных исключений, сделав функции приватными по умолчанию и т.д.). Java навязывает дисциплины, которые ценны для больших команд разработчиков.
- Функциональное программирование. Хаскела часто хвалят как самого чисто функционального языка. Присваивание является глагольным, и побочные эффекты невозможны, если только ваша функция явно не запрашивает их.
- Надежное совпадение. Erlang (еще один язык, поощряющий парадигму функционального программирования) известен своей робастностью в параллельной среде. Никогда не изучая и не используя его, я не могу лично поручиться за это, но его послужной список кажется впечатляющим
- Итеративное развитие. Там тонна евангелистов Липы . Они ведь не могут все ошибаться, правда?
- Быстрое 'n' грязное . Иногда просто нужно, чтобы сценарий был сделан быстро. Спасибо, Перл. ;)
Я думаю, что на самом деле вы ищете не язык программирования, который поощряет лучшие практики, а самоуверенный фреймворк веб-разработки.
Ruby on Rails, например, очень самоуверенный, и "из коробки" дает вам четкое представление о том, как фреймворк ожидает от вас взаимодействия с ним - он автоматически создает структуру проекта, и даже предоставляет некоторые начальные юнит-тесты. Тестирование является очень неотъемлемой частью разработки рельсов, и вы найдете много ресурсов для поддержки BDD, TDD и других хороших "гибких" методов разработки.
Другие фреймворки, такие как Django (python) и Seaside (smalltalk), вероятно, имеют свои собственные конвенции, хотя я лично с ними не знаком.
.Я собираюсь привлечь пламя и предложить Перла.
'WTF?' можно сказать. Perl имеет репутацию языка только для письма. Так и есть, когда в руках людей, которые используют его как язык супер-оболочки. Вы можете писать дерьмо на любом языке. Perl дает вам огромную свободу и гибкость. Так что, по логике Perl, у вас больше свободы в написании дерьмового дерьма.
Свобода и гибкость также может быть использована для обеспечения удобочитаемости и ремонтопригодности.
Но как научиться производить хороший код, а не дерьмо? В прошлом ответом был "Опыт и участие сообщества". За последние несколько лет появилось несколько новых инструментов и ресурсов, которые также могут помочь.
Опыт
- Если вы пишете дерьмо, и вам приходится его поддерживать, вы будете учиться на этом опыте.
- Прекрасно. Как избежать написания дерьма в первую очередь?
Сообщество
- Вместо того, чтобы навязывать произвольные правила в языке, Perl имеет культурные нормы, которые помогают улучшить код.
- Поставьте код на Perlmonks без строгих предупреждений, и вы услышите о том, почему вы должны их использовать.
- Отлично, значит, чтобы делать приличную работу, мне нужно проводить часы, читая сайты и группы новостей? Ну, теперь ты здесь. Но это все еще неоптимальное решение.
Инструменты: Вот тут мы и наткнулись на "Paydirt" -
- Несколько лет назад была опубликована Perl Best Practices. Она кодифицировала и собрала идеи многих лидеров сообщества Perl. В нем приводится подробное обсуждение аргументов, лежащих в основе каждой из 256 предложенных практик. Он предлагает практики и способ мышления о практике программирования.
- perltidy является отличным переформатором для Perl, который способствует удобству чтения кода, автоматически применяя стиль форматирования.
- Perl::Critic и поддерживающие его модули обеспечивают высоко конфигурируемую систему для анализа Perl-кода. Компьютер выходит далеко за рамки обычного lint и даже ссылается на конкретную страницу в Perl Best Practices для каждого найденного выпуска, позволяя вам улучшить свой код, пять уровней за пределами проверки синтаксиса.
- Unit testing является неотъемлемой частью культуры Perl. Perl предлагает отличные инструменты юнит-тестирования как часть дистрибутива 5.10. Дополнительные инструменты тестирования доступны в CPAN.
- Moose - это новая объектная система для Perl 5, вдохновленная объектной системой Perl 6. Moose предоставляет расширенные объектно-ориентированные возможности, такие как роли и черты. Роли и черты предоставляют новые мощные способы работы с составом кода и его повторного использования, выходящие за рамки возможного с наследованием, интерфейсами и микшированием. Наследование моделирует отношение "IS A". Модель ролей и признаков "DOES". Не могу не подчеркнуть, насколько это полезно.
я не могу полагать, что никто не упомянул Objective C / Какао. Вы поощряетесь повсюду следовать за узорами MVC, и свободный ввод допускает некоторые серьезно отделенные проекты OO.