Pull to refresh

Comments 12

Листинг 3.2 можно прямо на вредные советы разбирать. Однобуквенные переменные, какие-то приседания с n и n-1, объявление итераторов вне цикла, задание граничных условий не через Array.length(). Пробелы автору, судя по коду, вообще приходится по талонам получать.
Вы не удивляйтесь. Это же физики:

для магистров физического факультета Киевского национального университета


это вполне типично для инженеров и ученых именно так писать. У меня много таких знакомых было.

Сам выбор массивов как темы для презентации книги вас разве не смущает? Я вот не помню, чтобы я за много лет хоть когда-то завел в коде массив по своей инициативе — только тогда, когда чужой API его хочет на входе. Ну или там main(String[] args)… никуда не деться.

Но если у вас цель программы, например умножать матрицы (а такого добра полно), то такого типа код будет достаточно близок к исходной математической модели, и достаточно понятен для тех, кто его будет читать. То есть, для таких же инженеров или физиков. В компаниях, где софт основной продукт — наверное да, код бы и ревью не прошел.
Побуду адвокатом дьявола — в книгах(и документации) обычно не production-ready примеры. Их нельзя рассматривать как хороший образец оформления кода. Они призваны показать лишь конкретную фичу языка и такое встречается повсеместно, в том числе у признанных классиков.
Например Брюса Эккеля d Thinking In Java/On Java 8 объясняет это так:
Use examples that are as simple and short as possible. This sometimes prevents me from tackling “real world” problems, but I’ve found that beginners are usually happier when they can understand every detail of an example rather than being impressed by the scope of the problem it solves. For this I might receive criticism for using “toy examples,” but I’m willing to accept that in favor of producing something pedagogically useful.


P.S. Только что обнаружил, что Эккель написал книгу по Java 8 и вроде как бесплатно раздает Thinking in Java 4th edition.

И разве это служит оправданием? "Да это ведь учебная книга и поэтому мы будем вам писать код в отвратительном стиле" понятно что они учат языку программирования, но ведь стиль написания кода не менее важен чем умение работы с массивами.

Вы слишком категоричны, код должен читаться и отвечать на вопрос — «что здесь происходит?» Если в прикладной разработке ответ будет «печатается двумерный массив», то определенно что-то не так. Аналогично если в данном случае ответом будет «печатаются позиции фигур на шахматной доске», то определенно это не та мысль, которую хотел донести автор.
Еще стоит учесть, что код форматируется для чтения с бумаги — а там, например, отсутствие пробелов может наоборот быть плюсом.
ведь стиль написания кода не менее важен чем умение работы с массивами.

Безусловно, но об этом другие книги со своими примерами.

P.S. Иногда «начинающим» бывает сложно потом отвыкнуть везде называть переменные a, b и foo, но это довольно быстро проходит.
Как раз отбить плохие привычки иногда очень сложно. Поэтому начинающих лучше учить хорошему с самого начала. Например, примеры кода, которые я вижу, нихрена не тестируемые, потому что там в одном фрагменте смешаны две или более разных функций. Т.е. принцип единственной ответственности нарушается направо и налево. Типичный код «что вижу — о том пою».
Автор, судя по поверхностному гугляжу, прошелся чуть ли не по всем мейнстримовым языкам от си до джавы с питоном.

Такое бывает, если нагуглить не просто Ник, а ещё и смысл, который за ним скрывается — издательство Питер

AstarothAst вероятно имел ввиду автора книги — Алесея Васильева, который пишет про большинство мейнстрим языков. И, судя по обложкам, в Питере издается первый раз — пруфлинк.
Массив, массив, массив, массив… Как-то тяжело написано, имхо. С точки зрения восприятия слишком много повторений одних и тех же слов в одном предложении/абзаце. Про листинги уже писали вышел.
Sign up to leave a comment.