Собственно, одного взгляда на код достаточно, чтобы понять:
— пользуется ли собеседуемый каким-либо распространенным стилем кодирования;
— умеет ли более-менее сносно проводить декомпозицию;
Если посмотреть пару-тройку функций длиной в полэкрана, можно еще и понять предпочтения по проверке пред-условий, использование вложенных конструкций или вынос в метод, и т.д.
В общем, по коду можно понять, хороший это код или плохой.
Попробуйте лучше определить, нет ли на конце односвязного списка (о-очень большого) кольца, не используя дополнительной памяти (читай: массивов), не копируя элементы списка. Сложность алгоритма должна быть O(n).
P.S. Список заканчивается кольцом, если последний элемент списка указывает на один из элементов в середине списка.
Ага. Я вот лично считаю себя где-то средним программистом, но при этом пробные тесты SCJP прохожу на ура (увы, платить за сертификат пока не могу себе позволить), да и калькулятор выражений за пару часов напишу.
Я учился по книге стивена Прата. Очень доступно и подробно описано, включая тонкие мометы использования шаблонов и множественного наследования. Также в этой книге есть множество примеров и задач для самостоятельного решения (по-моему, даже с решениями).
Да, могут, но только в пределах своей компетенции. А, хотя они и довольно-таки мощные, некоторые отдельные фишки в некоторых IDE отсутствуют, причем в каждой — свои.
Например, в IntelliJ IDEA вроде бы все здорово, но иногда мне хочется форматировать не весь JavaDOC, а только пустые строки и @param, @return и т.д., при этом НЕ форматировать остальной текст. Увы, IDE этого не умеет, и приходится отрубать автоформатирование JavaDOC.
Оба стиля удобы по-своему.
— Для стиля с переносом скобки на новую строку характена наглядность, т.к. явно выделены блоки, но при этом, увы, используется очень много вертикального пространства.
— Для египетских скобок характерна чуть меньшая наглядность (наример, при 4-уровневых вложенностях if-for), зато места гораздо больше.
Я лично строго придерживаюсь того стиля, который принят в команде программистов, где я работаю. А личное предпочтение отдаю стилю с переносом.
P.S. Еще бы IDE выделяли блоки, а строки со скобками скрывали — и место бы экономилось, и наглядность повышалась.
Решение 2 сработает :-)
— пользуется ли собеседуемый каким-либо распространенным стилем кодирования;
— умеет ли более-менее сносно проводить декомпозицию;
Если посмотреть пару-тройку функций длиной в полэкрана, можно еще и понять предпочтения по проверке пред-условий, использование вложенных конструкций или вынос в метод, и т.д.
В общем, по коду можно понять, хороший это код или плохой.
P.S. Список заканчивается кольцом, если последний элемент списка указывает на один из элементов в середине списка.
Если учитывать факты, а не голословные субъективные утверждения.
А кривые руки — это уже следствие…
Например, в IntelliJ IDEA вроде бы все здорово, но иногда мне хочется форматировать не весь JavaDOC, а только пустые строки и @param, @return и т.д., при этом НЕ форматировать остальной текст. Увы, IDE этого не умеет, и приходится отрубать автоформатирование JavaDOC.
А также для документирующих комментариев типа JavaDOC.
— Для стиля с переносом скобки на новую строку характена наглядность, т.к. явно выделены блоки, но при этом, увы, используется очень много вертикального пространства.
— Для египетских скобок характерна чуть меньшая наглядность (наример, при 4-уровневых вложенностях if-for), зато места гораздо больше.
Я лично строго придерживаюсь того стиля, который принят в команде программистов, где я работаю. А личное предпочтение отдаю стилю с переносом.
P.S. Еще бы IDE выделяли блоки, а строки со скобками скрывали — и место бы экономилось, и наглядность повышалась.