Например, не по вертикали:
Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker
Или по вертикали:
Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker
Что вы предпочитаете и почему?
code-layout
whitespace
coding-standards
Джейсон Бейкер
источник
источник
:%s/\([^ ]\) \+/\1 /gЯ предпочитаю гибрид:
Это, по сути, номер 2 с исключениями для случайных линий, которые длиннее окружающих линий - чтобы не допустить значительного разнесения большинства линий.
источник
Вот еще один вариант макетов списков, основанный как на опыте, так и на образовании, полученном в ходе университетского курса, посвященного взаимодействию человека с компьютером, и нескольких книг, которые я прочитал по (G) дизайну пользовательского интерфейса и графическому дизайну. Я использую это для диалогов, а когда у меня есть энергия / время, для CSS (хотя обычно не для кода).
Как и у всех остальных, у него есть свои плюсы и минусы.
Плюсы:
Минусы:
НТН
источник
Я предпочитаю первый, но без вкладок (которые, я думаю, пустые); вместо этого только одно пустое место. Мне легче читать, когда данные не «похожи», как в данном случае. Это также усложняет (при редактировании таких данных) «неверное прочтение строки», т. Е. Когда у вас есть три строки, скажем, с номерами версий. И затем, редактируя один, вы случайно редактируете другой на своем месте.
Однако, когда данные похожи, имеет смысл поместить их в столбцы, как во втором примере (только если они не похожи, но вы понимаете, в чем дело).
источник
К сожалению, это вопрос стиля, это очень субъективно, и вы, вероятно, получите много противоречивых результатов. Кроме того, используемый стиль сильно зависит от того, как вы используете табуляции или пробелы.
Что касается моих двух центов, я предпочитаю вариант второй версии. Мне нравится это лучше всего:
Это самая читаемая и простая в использовании версия, которую я пробовал. Единственный реальный недостаток - это то, что мне нужно выяснить, что является самым широким полем, и иногда в конечном итоге приходится расширять все из них, когда одно слишком широкое (обычно это происходит только с CSS). Однако есть несколько моментов, которые необходимо учитывать.
Во-первых, я обычно предпочитаю табуляции, а не пробелы, однако фактические настройки табуляции меняются; например, я привык к 4-значным TAB для кода C (++) или HTML и 2-пространственным TAB для Pascal или кода на ассемблере, в то время как для некоторых вещей, таких как CSS, я не предпочитаю ширину TAB. Этот вариант достаточно усложняет ситуацию, но затем используемый мной редактор добавляет свои сложности. Некоторые редакторы позволяют вам устанавливать настройки вкладок для каждого языка, но некоторые этого не делают (даже те, которые имеют разные профили).
Вы можете избежать этого осложнения, отказавшись от табуляции в пользу пробелов. Поскольку код обычно написан шрифтом фиксированной ширины, использование пробелов работает нормально, тогда как если вы форматируете поля в форме, резюме или другом не кодовом тексте и используете пропорциональный шрифт, вам понадобятся табуляции для выравнивания ,
Я предпочитаю вкладки в целом, потому что даже с кодом фиксированной ширины я расстраиваюсь, когда приходится перемещаться по нескольким пробелам для каждой вкладки. Напомню, что старые IDE Borland имели возможность перемещаться по TAB (особенно по всей длине пробела) как один объект, а не как два, четыре и т. Д. Пробелов. Это сделало практичным вставку вкладок в виде пробелов, делая навигацию курсора легкой и быстрой. К сожалению, я не видел ни одного современного редактора Windows, способного сделать это.
Наконец, то, будут ли другие использовать ваш код, играет большую роль в выборе стиля. Обычно я единственный, кто использует мой код, поэтому я могу форматировать все по своему вкусу, не обращая внимания на редакторы или настройки других. Если вы работаете с другими, вам нужно будет принять их во внимание, поскольку они должны будут учитывать вас.
Таким образом, удобочитаемость хорошая и очень желательная, однако параметры и редакторы, которые вам и другим нужно использовать, будут важны при принятии решения. Если вы один, вы можете просто использовать наиболее удобный для чтения формат. Возможно, вам придется привыкнуть к его использованию, но это, вероятно, окупится в долгосрочной перспективе, особенно когда вам нужно вернуться к коду, который вы написали некоторое время назад: читаемость так же важна, как и комментарии, для понимания того, что делает код. Если вы работаете с другими, то вам нужно будет работать вместе, чтобы разработать какое-то руководство по проектированию для использования командой.
источник