Рубрика «Совершенный код» - 46

Приветствую. Поговорим о вертикальном выравнивании кода?
Итак, вдохновившись недавней статьей я понял как надо. Полностью автоматическое выравнивание + парсинг синтаксиса вещь конечно удобная, но нет. И у меня родилась идея. Мы просто даем программисту самому в каждом конкретном случае определить, по каким символам и в каких местах выравнивать код.
Работает это в любом редакторе и с любым текстом. Как-то так:
Вертикальное выравнивание кода + немного Punto
Сразу забрать приложение можно тут: sourceforge.net/projects/tnice/files/
(выделяем текст, жмем Ctrl+Shift+D, пишем символы выравнивания, жмем Ctrl+Enter)
А подробный мануал и принцип работы под катом.
Читать полностью »

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

В обновлённом варианте библиотеки synapse-frames исключительно просто описываются иерархические структуры данных и представляются любые подмножества таких структур.

Читать полностью »

Автоматическое выравнивание кода

Доброго времени суток.

Среди способов повышения читаемости кода, связанных с визуальным восприятием текста, можно выделить следующие:

  • Подсветка синтаксиса
  • Использование отступов
  • Вертикальное выравнивание

Первые 2 способа хорошо себя зарекомендовали и применяются практически во всех современных IDE и продвинутых текстовых редакторах. Третий же метод не нашел такого широкого распространения. Этот пробел, как с теоретической, так и с практической точки зрения, я постараюсь восполнить в этой статье.

Читать полностью »

Мне нравится рефакторинг. Нет, не так. Я люблю рефакторинг. Не, даже не так. Я чертовски люблю рефакторинг.
Я не переношу плохой код и плохую архитектуру. Меня коробит, когда я пишу новую фичу, а в соседнем классе творится полный бардак. Я просто не могу смотреть на печально названные переменные. Иногда перед сном я закрываю глаза и представляю, что можно было бы улучшить в проекте. Иногда я просыпаюсь в три часа ночи и иду к ноутбуку, чтобы что-нибудь поправить. Мне хочется, чтобы на любой стадии разработки код был не просто кодом, а произведением искусства, на которое приятно смотреть, с которым приятно работать.

Если вы хоть немного разделяете мои ощущения, то нам есть о чём поговорить. Дело в том, что со временем что-то внутри меня начало подсказывать, что рефакторить всё подряд, везде и всё время — не самая лучшая идея. Поймите меня правильно, код должен быть хорошим (а лучше бы ему быть идеальным), но в условиях суровой реальности не всегда разумно постоянно заниматься улучшением кода. Я вывел для себя несколько правил о своевременности рефакторинга. Если у меня начинают чесаться руки что-нибудь улучшить, то я оглядываюсь на эти правила и начинаю думать: «А действительно ли сейчас тот момент, когда нужно нарефакторить?». Давайте порассуждаем о том, в каких же случаях рефакторинг уместен, а в каких — не очень.Читать полностью »

Рабочий код != Хороший код
Когда я слышу фразу “Работает — не трогай”, мне хочется превратиться в большое зеленое существо и крушить все вокруг! Тот факт, что код работает, еще не значит что он хорош. В идеале, “код работает” — это только первая стадия, черновик, начало работы. Для большинства же, если код выполняет текущую бизнес-задачу — закоммитим и забудем.

Рабочий код написать не так уж сложно — нужно иметь немного мозгов и знать синтаксис языка. Для того, чтобы написать хороший код, нужно приложить куда больше усилий, однако, именно качество кода выделяет профессионалов среди огромного количества обычных кодеров. Под катом несколько субъективных советов о том, как писать хороший код.
Читать полностью »

Много статей написано о том, как правильно реализовывать на Java шаблон проектирования Singleton.

Как правило, специалисты ломают копья вокруг проблемы, как совместить корректную работу в условиях многопоточного использования и эффективное выполнение, обеспечивающее производительность, близкую максимальной.

Лично я считаю единственным корректным способом реализации синглтона на Java так называемый Synchronized Accessor:

public class Singleton {
    private static Singleton instance;
    
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Именно так задумывали реализацию подобной задачи авторы виртуальной машины Java, именно такая реализация используется в стандартной библиотеке классов языка Java. Если же для программы метод доступа к синглтону становится узким местом, то это повод для того, чтобы произвести редизайн программы, чтобы она обращалась к глобальному объекту не так часто.

Однако, пытаясь освежить в памяти возможности Java concurrency, я почитал старые статьи о вариантах синглтонов и удивился, что не нахожу описания еще одного способа, который я называю Function Pointer.
Читать полностью »

Довольно давно я делился проблемой тестирования кода в финализаторе и недавно жаловался на падение теста (Как тестировать код финализатора (c#) и Как тестировать код финализатора (c#). Послесловие: тест все-таки упал).
В ходе обсуждения комрадом withkittens была высказана идея:

Финализатор (при правильной реализации IDisposable pattern) должен (should) вызывать Dispose(false). Этот факт можно тестировать статическим анализом. Соответственно, если Dispose(false) вызывает удаление файла (вы же написали тест?), то можно быть уверенным, что и финализатор тоже вызовет удаление файла, unit-тест излишен.

Мне эта идея показалась очень здравой, кроме того, иногда хочется контролировать исходный код более кастомно, чем дает встроенный анализ кода или решарпер.
Опыт реализации кастомных правил анализа кода под катом + «как ozcode помог в процессе исследования внешней библиотеки»
Читать полностью »

imageЧитать полностью »

Снижение компонентной связности кода С++
Избавляемся от недостатков классического ООП и пишем на С++ в модульном стиле.
Читать полностью »

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

Коротко о проблеме

В Python есть встроенная функция eval(), которая выполняет строку с кодом и возвращает результат выполнения:

assert eval("2 + 3 * len('hello')") == 17

Это очень мощная, но в то же время и очень опасная инструкция, особенно если строки, которые вы передаёте в eval, получены не из доверенного источника. Что будет, если строкой, которую мы решим скормить eval'у, окажется os.system('rm -rf /')? Интерпретатор честно запустит процесс удаления всех данных с компьютера, и хорошо ещё, если он будет выполняться от имени наименее привилегированного пользователя (в последующих примерах я буду использовать clear (cls, если вы используете Windows) вместо rm -rf /, чтобы никто из читателей случайно не выстрелил себе в ногу).
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js