Pull to refresh

Comments 105

UFO just landed and posted this here
Для этого есть умные форматтеры. Жаль что очень немногие форматтеры это умеют. Вот, например, в astyle я этой рюшки не нашёл :(
UFO just landed and posted this here
И не только ОС, если для саблайма есть, тоже было бы здорово узнать.
Alignment устарел и больше не обновляется. На его основе создан VAlign, он получше будет.
Для Саблайма есть еще пакет «Абакус». Без настроек работает из коробки для любого языка.
Google => Elastic Tab Stops

P.S. Сорри, прямой линк дать не могу — мерзкая прокся на работе.
Чудно! Я по этому тэгу нашел редактор Code Browser. Преинтереснейшая штучка, надо доложить.
Сейчас немного покапался и оказалось, что в VS выравнивание присваиваний делается нативно комбинацией Ctrl+Alt+]
И ещё Align.vim — позволяет выравнивать по регулярным выражениям
Проблема еще в том что после выравнивания вы затрете аннотейты у выровненных строк. В большом проекте где много народу это серьезная проблема, ибо самая лучшая документация это дата имя и коммент человека сделавшего правку.
Полностью согласен. Поэтому в разработке и не использую.
git blame -w

В эклипсе также можно настроить игнор аннотаций с изменениями только white-space`ов.

Аргумент не принимается :)
А как эта фича будет работать с изменением пробелов в строковых ресурсах/переменных? Есть ли аналог у ртути?
вы контроль версий что ли не используете? Blame никто не отменял
Не только бессмысленно но и плохо. При поддержке, рефакторинге, фиксинге, вместо одной измененной строки, получается много. Это касается любого выравнивания по длине чеголибо.
Верно; но, оказывается, не всегда. Например, чуть выше GooRoo говорил про Elastic Tabstop. С соотвествующей поддержкой в редакторах править строки выше и ниже не требуется.
Выравниваю, если разница не более 4 пробелов.
Если такого кода больше половины экрана подряд, то выравниваю, иначе можно долго всматриваться чтобы найти значение переменной:)
PhpStorm это умеет автоматом делать,
но я ровняю только в случаях с большими массивами (например описывающими меню)
у меня настройка автоматом выравнивает, если не влезает по ширине до 120 символов и делается перенос
Выбрал «Не выравниваю код» и нажал «Воздержаться». Facepalm.jpg
стараюсь выравнивать, а вот эклипсовый автоформатер порет все мои старания
разве эклипсовый автоформатер нельзя настроить чтобы он не порол старания?
не осилил. гугл тоже не помогает. с благодарностью отнесусь к подсказкам благородных донов
Window -> Preferences -> Java -> Code Style -> Formatter -> [Edit | New] -> Indentation -> Align fields in columns
Window -> Preferences -> С++ -> Code Style -> Formatter -> [Edit | New] -> Indentation -> Align fields in columns
мне жаль вас огорчать, но этот чекбокс есть только в пути, приведенном уважаемым vasart
версия эклипса:

Version: 4.2.2
Build id: M20130204-1200

cdt:
8.1.2
Хм, странно, у меня тоже нет для плюсов, подумал у вас просто Eclipse CDT отсутствует) Хотя, как бы вы писали на плюсах тогда))
В Netbeans, использую автоформатирование (ALT+SHIFT+F).
А мне показалось, что код на Ruby :)
Если посмотреть код страницы, то видно, что в атрибутe class тега code стоит python ;-)
UFO just landed and posted this here
1) Если таких данных 2-3 и они в коде — не выравниваю
2) Если это заполняемая структура ( хэш, массив или что либо еще ) — обязательно выравниваю — читается все это потом гораздо легче.
Такое выравнивание уже давно бессмысленно. То ли в Чистом Коде, то ли в Совершенном Коде про это тоже написано.
«уже давно бессмысленно» подразумевает, что раньше у этого был какой-то конкретный смысл, а потом по каким-то объективным причинам он исчез.
«Чистый Код», стр. 114. Дядюшка Боб использовал такое выравнивание, когда писал на Ассамблере. Поэтому я предположил, что когда-то такое имело смысл.

Для себя смысла никогда не видел.
Нажал «Мне по барабану», имея в виду «зависит от ситуации».
Раньше вы равнивал, но потом получил замечание, которое застравило переосмыслить. После изменения/добавления строки кода приходится изменять все близлежащие строки, что негативно отражается на размер дифа после коммита. Это делает запутанным определение авторов изменений тех или иных строк и делает бесмысленным git blame

Так же в сложных js проектах придерживаюсь npm code style
Выравниваю группу связанных переменных, например коды ошибок, причем подобное выравнивание как раз и указывает на взаимосвязанность выравниваемых данных.
Для SublimeText есть плагин Alignment, отлично выравнивает. Выделяем (CTRL+ALT+A) и готово. Он кстати не только по столбцам выравнивает…
Когда как:

// большой блок переменных близких по смыслу, выравниваю
date     = controller->getDate();
period   = controller->getPeriod();
object   = controller->getObject();
property = controller->getProperty();
id       = controller->getId();

// далее выравнивать нет смысла, так как переменные разные по смыслу, да и замучаешься равнять 
model = new Model(object, period);
result = model->getResult(id, date);
propertyValue = result->getPropertyValue(property);
Именно! Без вашего варианта опрос не полноценен.
Собственно сам открыл комментарии, чтобы написать такой же вариант. Ответил «Выравниваю», но это все-таки не совсем верно.
И весь код солянка, половина так половина так, и смыслы потеряются или поменяются при рефакторинге.
Не половина так, половина так, а везде по уму, чтоб читабельность была нормальная, рефакторинг этому не помешает.
«По уму» половина так, «по уму» половина так, ничего не меняется. Я написал, что в процессе рефакторинга, «по уму» может менятся. Рефакторингу мешает любые сортировки «по уму». Сортировать нужно не по уму а по использованию. Чтобы дистанция между связанными объектами была минимальна. Есть такие метрики, не помню как они называются. Статистически чем меньше расстояние тем меньше вероятность ошибок.
Рефакторил огромные проекты, написаные и студентами и очень умными людьми. И у всех «по уму» сильно разнится. И то что «по уму» для архитектора не всегда очевидно «по уму» для среднего имплементатора.
Любые «по уму» в топку, никаких вырвниваний, никогда.
Еще добавлю, что «выравниватели кода» это особый подвид программистов, которые не понимают, что не у всех шрифт mono. И взглянув на список переменных которые в развалку разбросанны по коду, отпадает желание ревьювить этот огород.
Почему «У всех»? По уму это делается автоформатом при просмотре кода и игнорирутеся при коммите, каждому под свой шрифт настроить не проблема. Переменные тоже никто не мешает в code-browserе каком-нить смотреть, если код не ваш.
Наоборот: foo, habrahabr = 'bar', 'Hello, world!'
Но это, если в приемлемую длину строки укладывается. Предпочитаю инициализацию в одну строчку, чем размазанную на пол экрана.
<моя любимая среда разработки> сама при реформатировании кода делает выравнивание согласно моим пожеланиям. соответственно, пока пишу выравнивания нет, но достаточно нажать Ctrl+Shift+F, как всё сразу выстраивается в колоночки — что переменные с объявлениями, что массивы, что параметры у вызываемых функций/методов
Стараюсь выравнивать, т.к. 90% времени код читается. Если код пишется на раз-два и выкинуть, то тогда конечно не надо равнять.

При необходимости обновить выравнивание, анноации (blame) нифига не теряются. Но это только в рассово-верных а-ля git, eclipse. Возможно и в других.

git-blame -w

В эклипсе:
Если идёт большой блок инциализации / объявления — могу и выровнять (когда писал на делфях — всегда выравнивал), а вот в Java такая потребность почти всегда отсутствует — грамотная подсветка синтаксиса + не линейная инициализация переменных (чаще всего переменные рассыпаны по коду).
грамотная подсветка синтаксиса


а представьте, что кто-то будет читать ваш код в блокноте, и он будет знать ваш адрес… :)
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.» © Стив Макконнелл
Вы правильно поняли мой намек :)
Очень часто смотрю код в блокноте. Никаких проблем нет.
Ну в таком случае — это проблема «смотрящего код в блокноте».
Адекватный проект на Java — это десятки, сотни и больше классов, в таком случае или знаешь проект и действительно можешь «глянуть в блокноте» (но при этом не потеряешься — ведь ты его знаешь) или смотреть в блокноте бесполезно — зачастую надо открыть куда больше одного класса и заранее нужные файлы ты не знаешь.
Хотя с теми же константами (которые очень часто сидят в одном месте) я поступаю именно выравнивая в столбец. А вот с инлайн-переменными это почти всегда неразумно.
gofmt и радуюсь жизни. Он автоматически выравнивает, но не во всех местах, только там, где это действительно уместно.
Не выравниваю и не люблю. Мне в вашем примере кажется, что bar больше логически относится к hello world, чем к foo. Попробуйте почитать оглавление у книг, если в них убрать "...", они тоже выровнены красивенько.
В питоне не выравниваю, ибо PEP8. (аналогично и с большинством других языках) В случае же если пишу на Go, то выравниваю.
выравниваю только наборы почти однотипных и близких по длине строкового представления данных
Лично я, когда как. А точнее в разных ЯП по разному. Например, на Python не выравниваю, придерживаюсь PEP8
По мне, надо смотреть по самому коду и что вокруг, не понравилось — под равнял, на вкус и цвет фломастеры разные…
Макконелл, кстати, не советует выравнивать. Мотивирует тем, что такое определение переменных сложнее в сопровождении, а значит на него вскоре забьют.
Иногда выравниваю даже числа в массиве. Или фрагменты формулы, разбитой на несколько строк. Но это если действительно важно соответствие между символами кода в разных строчках. В приведённом примере выравнивал бы, если бы весь блок (конструктор, задание структуры, enum) состоял бы только из строчек вида a = b. Если же это фрагмент функции — скорее всего, нет.
Выравниваю, хоть и без особого фанатизма. Например, нет смысла выравнивать такое:
// some code here
...


$short = 'some value of short variable';
$someLongVariableNameHere = 'value of long variable name';

// and code here
...


Две-три переменные, с настолько разной длиной имён… Ерунда вобщем.
А вот в групповых присвоениях: массивы, группа свойств, блок переменных — тут уже для удобочитаемости выравниваю. Тем самым облегчаю дальнейшее сопровождение кода: читается выровненный блок намного проще.
Не выравниваем. Читаемости не добавляет, а поддерживать сложнее.
Использую возможности IDE по автоформатированию, а она не выравнивает.
Может просто настройки по дефолту, а вообще она умеет? :)
Мне не нравится такое выравнивание: если идет несколько строк с большим расстоянием между = и значением — то приходится целиться пользоваться глазомером, чтобы проследить от знака = направление к значению. Это лишнее напряжение и есть возможность запутаться.
Когда копал исходники Qt заметил, что выравнивание у них есть (например для дефайнов), но табуляция сделана с большим допуском, отчего возможные будущие добавленные строки будут хорошо вписываться в стиль.

Сам же стараюсь выравнивать только в случаях однотипных или связанных по смыслу данных.
UFO just landed and posted this here
А как? Попробовал на .rb и .coffee файлах, сам RubyMine ничего не выравнивает за меня.
UFO just landed and posted this here
Так оно само не равняет по ходу печати, все равно нужно строки выделить и Code — Reformat сделать (alt+cmd+L)
UFO just landed and posted this here
Хорошо конечно, просто я думал оно само, нажал переход на новую строку, а оно бац и все выше строки поравняло. А так в общем-то удобная фишка, которой мне с перехода SublimeText2 (плагин Align) не хватало.
UFO just landed and posted this here
Ну да RM не плохой, хотя держу его в целом только из-за отличного автокомплита и удобства найти исходник метода (клик по методу с зажатым cmd), а так бы и сидел до сих пор в Sublime Text2, тот же плагин выравнивания там очень легко подстраивается под любые языки от Python до CoffeeScript.
А я выравниваю только объявления в хедерах — те, что идут в публичное API.
А в реализации — как получится. Обычно это только тратит время и создаёт «дырки» в тексте, а практической пользы нет.
Выравниваю (и именно так ответил в опросе).

Но выравниваю только тогда, когда переменные близки и по длине имён их, и по смыслу их употребления в коде.
Ответил выравниваю, но не везде…
выравниваю при описании структур, констант и пр…

static pthread_mutex_t stats_mutex	= PTHREAD_MUTEX_INITIALIZER;
static pthread_mutex_t accept_lock	= PTHREAD_MUTEX_INITIALIZER;

extern int				max_clients;
extern fd_ctx				*clients;
extern int 				is_finish;
extern int 				is_trace;


static const int const_RN_len		= 2;
static const int const_END_len		= 5;
static const int const_END2_len		= 7;
static const int const_OK_len		= 4;
static const int const_ERROR_len	= 7;

typedef struct {
	ev_io		io;			/**< io descriptor */
	int		cmd_len;		/**< bytes in line buffer */
	struct obuffer 	response;		/**< response data */
	char*		value;			/**< key value from last set command */
	int		value_len;		/**< number of bytes in value buffer */
	int		value_size;		/**< capacity of value buffer */	
	int		data_size;		/**< value   size into cmd */	
} mc_ctx;




не выравниваю просто в коде

int i = 0;
char* state = STORED;


на вкус и цвет — товарищей нет
Выравниваю, но без фанатизма. Вышеприведенный пример я оформил бы так:

extern int     max_clients;
extern fd_ctx  *clients;
extern int     is_finish;
extern int     is_trace;

static const int const_RN_len    = 2;
static const int const_END_len   = 5;
static const int const_END2_len  = 7;
static const int const_OK_len    = 4;
static const int const_ERROR_len = 7;
Почти невозможно понять SQL-запрос на 4-5 экранов без правильного форматирования.
Так что выравниваю, свои скрипты — в момент написания, чужие — форматтером (аддоном для MS SQL Management Studio).
www.ssmsboost.com/

Форматтер не лучший и возможности настроить его я не нашел, но по сравнению с неотформатированным код смотрится гораздо лучше.
Плюс там есть еще другие полезные фишки, которые иногда использую.
Нет варианта — использую автоформат в IDE. Мне по барабану, главное чтобы было единообразно.
При объявлении переменных не выравниваю, а во всех остальных случаях выравниваю, особенно когда создаю массив с кучей табличных/статичных данных.
Sign up to leave a comment.

Articles