> -- Илья Ермаков писал(а):
> Ну, понятие стиля - это нечто из лексикона программистов, математиков, литераторов... И связано с текстом.
Не всегда стиль - лишь результат совокупности типичных, "привычных" приёмов по оформлению текста (расположение, вид переменных, отступы, пустые строки)...

Возьмём поэзию... Например, стихи Маршака или Михалкова узнаваемы. А уж про Бродского, Маяковского (позднего) или Сашу Чорного - и говорить не приходится!
Даже в своих переводах с других языков они узнаваемы. Шекспира Пастернака не спутаешь с маршаковским и оба ни в какое сравнение не идут с  Лозинским! А уж как последний переводил Киплинга - СКАЗКА! Разве здесь важен ТЕКСТ? Да - ни в коей степени! Или - не в первую очередь! Важен внутренний ритм, передача мелодики, ритмики, нарастание и спад мелодических ударений в строфах и частях, следование (угадывание) общего смысла и настроения переводимого автора. Почему я именно на переводческую работу обращаю внимание? Потому, что она сродни тому, чем мы занимаемся в нашей отрасли: мы на языке программирования отражаем наши мысли, системы, логические ходы рассуждений и решений. Как бы "замысел", в случае перевода поэтического произведения - уже есть. Он как-то уже запечатлён ("формализован" особыми приёмами). Но - на другом языке. Хотя и сказано, что мысль изреченная есть ложь, но по-иному, пока не научились...То есть, мысль, идея, план повествования и "развёртывания", передачи идей - уже сделан. Надо только его "вербализировать" на другом языке - практически заново изречь.
Как это сделать, кроме того, что записать буквами алфавита другого языка слова-аналогии этого языка?
Вот тут и начинают "играть" неявные стили - способы выражения своих мыслей.
И, смотрите, что выходит:
(удивительно! вознамерился искать по-отдельности для иллюстрации, примеры, а какой-то хороший человек угадал заранее моё желание и поместил все переводы на одной страничке! даже те, про которые я и не слышал! спасибо этому человеку! )

http://www.iis.nsk.su/news/events/20050 ... ling.shtml

(Кстати, заметьте, что перевод Лозинского идёт раньше Маршака! Ну, понятное дело, что перевод Ершова - первый после оригинала, но смотрите, насколько точно строй стиха Лозинского передаёт речь и идеи Киплинга. Перевод Лозинског практически можно заучить читая!)

Вернёмся к программированию.

Когда я говорю о "стиле", я не оформительские вопросы больше имею в виду, а - стиль способа отображения семантики и описаний структур задачи на соответствующие элементы языка программирования и текста программ. Здесь стиль имён, расположение управляющих конструкций, форма представления и расположения описаний - вторичны. Более важен стиль оперирования с информацией, анализ условий и состояний (способ их получения, хранения и представления внешним сущностям, логические выделения моментов их рождения, "означивания", переназначения, гибели), выделение ключевых мест, связанных с описанием правил и дисциплины привязки жизненных циклов элементов программы.

Ну, вот помните, я как-то написал, что обычно в методе-"действии" выполняю основные операции после всех проверок в предусловиях? И в этих проверках, в случае негативного ответа, - немедленно покидаю программу через оператор возврата. Это  - именно вопрос стиля: проверка всех условий, которые НЕ позволяют выполнить затребованную операцию и "некрасивый", "внеструктурный" выход из метода! Почему? Потому, что невыполнение предусловия - "бяка". Нечто неприятное, "резкое", "ненормальное". И я таким, "колющим" восприятие, образом акцентирую внимание на местах покидания метода "нехорошим", "нештатным" способом.

То же самое, например, - про способ объявления переменных и их МЕСТА: я стараюсь объявить (и - проинициализировать, по возможности и логике) текстуально максимально близко к первому месту, где эта переменная будет использоваться.
Одна из причин - в алгоритмах ветвления с вложенностью больше двух, разные ветки прохождения трассы программы могут потребовать введения разного набора переменных (разных типов). Практически, может оказаться, что разные подветки решения - просто кардинально различающиеся алгоритмы (и не всегда имеет смысл выносить-оформлять их в отдельные функциональные единицы). Так зачем же мне путать читателя моей программы и "забивать" ему мозги кучей промежуточных переменных, описываемых в начале тела метода? "Переиспользованием" одних и тех же переменных в разных ветвях алгоритма я, может быть и экономлю память (стек?), но зачем же нагружать пользователя разной семантикой и её учётом в зависимости от подветки алгоритма? Пусть всё будет иметь зоны максимально ограниченной ответственности! - порядка двух-десяти строчек!

И т.д.