Здравствуйте, Sinix, Вы писали: S>Здравствуйте, telek1024, Вы писали: S>Чтоб понятней было, что имею в виду: S>
Скрытый текст
S>
S> private static PathToken ParseToken(PathTokenInfo parsingToken)
S> {
S> PathToken result;
S> if (IsCurrentDirectoryToken(parsingToken))
S> {
S> result = CurrentDirectoryToken.Instance;
S> }
S> else if (IsParentDirectoryToken(parsingToken))
S> {
S> result = ParentDirectoryToken.Instance;
S> }
S> else
S> {
S> string tokenName = GetNormalizedTokenName(parsingToken);
S> if (parsingToken.SeparatorCount == 0)
S> {
S> result = new FileToken(tokenName);
S> }
S> else
S> {
S> result = new DirectoryToken(tokenName);
S> }
S> }
S> return result;
S> }
S>
Ну вот у вас каждая строка, которая хоть что-то делает отделена от другой минимум одной строкой, которая ничего не делает. Такой код занимает больше места и приходится дольше скролить.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, okman, Вы писали:
O>>К примеру, я могу обосновать почти каждый элемент своего стиля. A>объясни сдвиг скобки: A>
A> if (state->flags & 0x0400)
A> {
A>
A>PS. а раз мы всё же в КСВ, я бы за такой сдвиг расстреливал
Сдвиг скобки сейчас объясню (по причине того, что мы в КСВ ).
Хотя ее положение непринципиально, можно ее и без отступа писать.
Скобка — это начало вложенного блока. То есть, она все же имеет большее
отношение к этому блоку, чем ко внешнему, поэтому и должна быть с ним на одном уровне.
Но абстрактно. Лично я и так и так писал, в разное время.
Здравствуйте, telek1024, Вы писали:
... T>Лично я не люблю стиль вида T>
T>if (a == b)
T>{
T> ...
T>}
T>
T>Мне он кажется слишком разреженным. Получается принудительная пустая строка, а иногда это мешает.
А я наоборот предпочитаю. Не люблю, когда все поналепят в кучу, не поймешь, где начало, где конец блока, особенно когда их несколько.
А еще комментарии "разрежают" код Но ведь и мониторы то давно уже не 80 на 25 строчек
Здравствуйте, telek1024, Вы писали:
T>Ну вот у вас каждая строка, которая хоть что-то делает отделена от другой минимум одной строкой, которая ничего не делает. Такой код занимает больше места и приходится дольше скролить.
Мне редко приходится скроллить: методы небольшие, переход — ctrl-click. Кода много, куда важнее быстро понять что он делает (особенно, если долго с ним не работал).
Я пару раз выше давал дисклеймеры — мы делаем так, как удобно нам. Если вам так неудобно — лучше делитесь своим, чем доказывайте как же я неправ
Здравствуйте, okman, Вы писали:
O>... При виде закрывающей фигурной скобки хочется сразу отыскать ее O>"старшую сестру", чтобы мысленно обозначить выделенный ими кусок кода, а для этого приходится бегать O>глазами и выискивать конструкции типа if и while...
А я не ищу "старшую сестру". Да и на "младшую" обычно внимания не обращаю. Хватает отступов.
Здравствуйте, okman, Вы писали:
O>Сдвиг скобки сейчас объясню (по причине того, что мы в КСВ ). O>Хотя ее положение непринципиально, можно ее и без отступа писать.
вообще-то принципиально — выделить границы блока. в твоём случае границы блока в виде скобок сливаются с самим блоком, и границей блока зрительно кажутся части внешнего блока. и нафиг в таком случае тратить две строки на скобки, непонятно.
Здравствуйте, Antikrot, Вы писали:
A>в твоём случае границы блока в виде скобок сливаются с самим блоком, и границей блока зрительно кажутся части внешнего блока. и нафиг в таком случае тратить две строки на скобки, непонятно.
Если честно — я не понял про границы. Можно "на пальцах" ?
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Antikrot, Вы писали:
A>>в твоём случае границы блока в виде скобок сливаются с самим блоком, и границей блока зрительно кажутся части внешнего блока. и нафиг в таком случае тратить две строки на скобки, непонятно.
O>Если честно — я не понял про границы. Можно "на пальцах" ?
Если скобки с отступом, вот так:
if(условие)
{
какой-то код
}
то скобки не выполняют ф-цию визульного выделения блока (или границ блока). Их можно убрать, как сделали в Питоне, например.
Здравствуйте, CreatorCray, Вы писали:
CC> Ну, я к примеру паскаль освоил раньше чем С, и помню с каким облегчением избавился от опостылевших begin end.
У меня все было ровно наоборот И из-за этих скобок (и, как правильно заметил ТС, разного стиля их использования) я жутко не люблю сишные исходники читать.
Здравствуйте, okman, Вы писали:
O>Ужасно ! Тут же черт ногу сломит !
Это стандартный K&R-стиль. В таком стиле написаны тонны говнокода. Нравится он вам или нет, но в таком стиле надо уметь читать. Хотя замечу, сам я предпочитаю фигурные скобки на отдельной строке, и чтобы тело if'а и цикла тоже было на отдельной строке, даже если оно тривиальное (в случае тривиального без отдельных скобок, впрочем).
O>Или это какой-то всеобщий заговор, или code convention, которому следуют, не задумываясь ?
Здравствуйте, okman, Вы писали:
O>Здравствуйте, sc, Вы писали:
sc>>Если скобки с отступом, вот так: sc>>
sc>>if(условие)
sc>> {
sc>> какой-то код
sc>> }
sc>>
sc>>то скобки не выполняют ф-цию визульного выделения блока (или границ блока). Их можно убрать, как сделали в Питоне, например.
O>Все равно непонятно. Как это не выполняют ? Так, что ли, лучше:
O>
O>if (условие 1) {
O> какой-то код
O> } else if (условие 2) { еще код
O> } else
O> { ну и еще немножко кода
O>}
O>
O>[/ccode]
теперь я уже ничего не понял
вот исходный код, немного "причесанный"
if (условие 1)
{
какой-то код
}
else if (условие 2)
{
еще код
}
else
{
ну и еще немножко кода
}
здесь каждая пара скобок {} выделяет отдельный блок. если скобки сделать так:
if (условие 1)
{
какой-то код
}
else if (условие 2)
{
еще код
}
else
{
ну и еще немножко кода
}
то блок выделятеся уже не скобками {}, а отступами. Следовательно визуальную ф-цию выделения блока скобки не выполняют. Следовательно скобки можно убрать. Такой подход применили в Питоне.
Здравствуйте, sc, Вы писали:
sc>Здравствуйте, telek1024, Вы писали: sc>... T>>Лично я не люблю стиль вида T>>
T>>if (a == b)
T>>{
T>> ...
T>>}
T>>
T>>Мне он кажется слишком разреженным. Получается принудительная пустая строка, а иногда это мешает.
sc>А я наоборот предпочитаю. Не люблю, когда все поналепят в кучу, не поймешь, где начало, где конец блока,
Та же фигня была. Потом научился определять по отступам.
sc>А еще комментарии "разрежают" код Но ведь и мониторы то давно уже не 80 на 25 строчек
Сейчас популяризуются ноуты. Так что можно считать, что экраны "сузились".
Здравствуйте, dilmah, Вы писали:
D>еще K&R использовали такой стиль
когда они его использовали, размеры мониторов и разрешение были совсем другими, а стиль говенный, независимо от того, кто его использовал. Нужен он только там, где есть необходимость экономить пространство, на сегодняшний день это только книги.
И>когда они его использовали, размеры мониторов и разрешение были совсем другими, а стиль говенный, независимо от того, кто его использовал. Нужен он только там, где есть необходимость экономить пространство, на сегодняшний день это только книги.
выше уже упомянули ноуты.
Скажем, сегодняшний google code style использует этот стиль и накладывает 80-символьное ограничение.
Здравствуйте, dilmah, Вы писали:
D>Скажем, сегодняшний google code style использует этот стиль и накладывает 80-символьное ограничение.
Во-первых, при чем здесь 80-символьное ограничение, если оно по ширине, а не по высоте? Хотя и его считаю уже не актуальным. А во-вторых, сейчас полно ноутбуков с нормальными дисплеями и разрешением. У меня 15 дюймовый ноут, вполне нормально.
).
