Copy Source | Copy HTML
- /* off_t might have a wider range than ssize_t - in other words,
- the max size of a file might be bigger than the address
- space. We can't handle a file that large. (Anyone with
- a single source file bigger than 2GB needs to rethink
- their coding style.) Some systems (e.g. AIX 4.1) define
- SSIZE_MAX to be much smaller than the actual range of the
- type. Use INTTYPE_MAXIMUM unconditionally to ensure this
- does not bite us. */
- if (file->st.st_size > INTTYPE_MAXIMUM (ssize_t))
- {
- cpp_error (pfile, CPP_DL_ERROR, "%s is too large", file->path);
- return false;
- }
-
- size = file->st.st_size;
Повышение качества javascript кода. JSLint

Случилось так, что в последнее время мне пришлось читать и рефакторить очень много ужасного javascript-кода. Работа с таким кодом стоит очень многих нервов при сопровождении, да и писать/отлаживать такой код не приятно. Мысли о том, что заставляет людей писать плохой код и как с этим можно бороться заставили меня писать эту статью. Не претендую на сколь-нибудь полное раскрытие темы борьбы за качество кода, хочу рассмотреть лишь некоторые аспекты, доставляющие наибольшее количество проблем. В качестве основного инструмента оптимизации качества кода предлагаю использовать JSLint, который несмотря на все плюсы, не является панацеей и может служить лишь отправной точкой для дальнейшего улучшения кода.
Всех у кого хоть раз болела голова при написании/чтении javascript кода прошу под кат.
Code Like a Pythonista: Idiomatic Python (part0)

От переводчика:
Я только начал изучать Python. С самого первого знакомства язык порадовал симпатичными конструкциями и синтаксически-гарантированной удобностью к чтению и пониманию кода.
В процессе освоения, при написании своего кода, бывает, сомневаюсь в правильности выбранных способов с точки зрения Python-way ( PEP 8 — Style Guide for Python Code, если угодно). Для вникания в идеологию программирования, в Python-сообществе кроме исчерпывающей документации, ко всеобщей радости, накоплено уже немало вспомогательных материалов, таких как статья Python Tips, Tricks, and Hacks, перевод которой недавно появился на Хабре
Мне понравилась статья Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python» (David Goodger «Code Like a Pythonista: Idiomatic Python»). Для лучшего её усвоения решил оформить (в силу умения) полноценный перевод, потом показалось здравой идеей поделиться с Хабром.
Пока работал над переводом, пришло понимание, что статья существенно больше, чем показалась при прочтении ее в оригинале, поэтому постить буду частями, чтобы не выпасть из формата Хабра-статьи.
Продолжение и окончание перевода.
Code Like a Pythonista: Idiomatic Python (part1)

Это продолжение перевода статьи Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python»
Начало и окончание перевода.
Спасибо всем хабраюзерам за оценки первой части, ценные замечания и положительные комментарии. Постарался учесть ошибки, снова жду конструктивного обсуждения.
Code Like a Pythonista: Idiomatic Python (part2)

После небольшого перерыва представляю заключительную часть перевода статьи Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python»
Ссылки на первую и вторую части.
Еще раз подчеркну, автор в этой статье не открывает Америку, большинство Питонистов не найдут в ней какой-то «особой магии». Но довольно подробно перечисляются методологии использования и выбора различных конструкций в Python с точки зрения удобочитаемости и близости к идеологии PEP8.
В некоторых местах в авторской статье отсутствуют примеры исходных кодов. Разумеется, оставил как есть, придумывать свои не стал, в принципе должно быть понятно, что имел в виду автор.
Совместная работа над кодом в компании Google

Как известно, в Google существует возможность использовать двадцать процентов своего рабочего времени в целях, отличных от целей текущего проекта (но в целях и интересах компании в целом). Это явление называется групплеты (grouplet) (об этом можно почитать в замечательной статье «The Google Way: Give Engineers Room», или в переводе этой статьи здесь), соответственно, у каждого разработчика может появиться дикое желание порыться в чужом коде и поучаствовать в каком-то проекте. А поскольку таких проектов, мягко говоря, много, то требуются некоторые формальные правила, которые позволят поддерживать весь код в актуальном состоянии и не позволят его качеству опускаться ниже определенного уровня.
Оформление кода → Разделитель вначале
Традиционный египетский способ представления:
- var userList= [
- { name: 'Tom', Age: 5, race: 'cat' },
- { name: 'Jerry', Age: 3, race: 'mouse' },
- { name: 'Spike', Age: 11, race: 'dog' }
- ]
* This source code was highlighted with Source Code Highlighter.
Обратите внимание, что в конце каждой строчки стоит запятая, кроме последней — там запятой быть не должно. Проблема в том, что при перестановке строчек местами и прочей копипасте ускоряющей процесс написания кода, нужно очень внимательно следить за запятыми, а так как они не навиду, это неизбежно приводит к ошибке.
Представление с разделителем вначале:
- var userList=
- [ { name: 'Tom', Age: 5, race: 'cat' }
- , { name: 'Jerry', Age: 3, race: 'mouse' }
- , { name: 'Spike', Age: 11, race: 'dog' }
- ]
* This source code was highlighted with Source Code Highlighter.
Оформление кода → Атомы
Несколько примеров:
- var user= new User( 'tenshi' )
- var isUser= anElement.hasClassName( 'user' )
- var container= document.getElementById( 'user' )
Тут мы видим много различных сущностей имеющих одно имя: имя переменной, имя конструктора, имя класса, идентификатор. Что если вы заглянули в исходный код страницы и обнаружили у одного элемента класс 'user', которого там быть недолжно? Из-за того, что имя класса не является для вашего приложения атомарной сущностью (то есть требует дополнительный контекст типа var, new, hasClassName, getElementById, чтобы обрести смысл), поиск по строке «user» выдаст вам гору всякого мусора, который придётся разгребать руками.Автоматический контроль структуры класса

Частые проблемы:
- конструктор неожиданно появляется в середине класса;
- внутренний класс объявлен где-то в середине внешнего класса;
- абстрактный метод объявлен где-то в середине большого абстрактного класса;
- @Autowired метод тоже расположен где угодно но только не на самом видном месте;
- статические билдер методы разбросаны по коду класса;
- поле класса затерялось где-то между внутренним классом и методами.
Надоело такое терпеть в коде?
Фашизм в коде. Часть вторая

Qt Coding Style

Привет, хабражители!
Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.
Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше…
10 моих любимых функций CodeRush для .NET разработки в Visual Studio

Вкратце, DevExpress CodeRush — это платный плагин для Visual Studio, относящийся к классу productivity tools, который позволяет разработчику быстрее писать более качественный код, отлаживать его, запускать тесты, обнаруживать дефекты и выполнять другие полезные функции.
В этой статье я постарался собрать не просто список своих собственных предпочтений по его использованию, но и провести небольшую валидацию так, чтобы на выходе большинство из представленных фишек использовались другими ребятами в моей команде. Я считаю, что даже несмотря на активное развитие Visual Studio (особенно порадовала 2012я версия) и превращение некоторых из описанных функций в нативные, необходимость в сторонних помощниках типа CodeRush и ReSharper все еще актуальна для части разработчиков, так как позволяет сэкономить время и повысить общее удобство кодирования. Наконец, не стоит забывать, что еще достаточно разработчиков сидят на Visual Studio 2010- (как минимум сужу по множеству заказчиков) ввиду особенностей проекта, бюджета или просто привычки.
Итак, кому интересно узнать, что другие .NET разработчики используют для повышения эффективности пусть и малой, но не менее увлекательной части процесса конструирования программного обеспечения, прошу пожаловать под кат (внимание, много картинок и видео, а также опрос!)
Советы по созданию приложений к окончанию набора в Школу мобильной разработки Яндекса

Традиционно задание построено так, чтобы мы могли обратить внимание на разные аспекты разработки. К ним относится архитектура приложения, стабильность, производительность, верстка, удобство использования. Все составляющие одинаково важны: даже идеально причесанный и разложенный на слои код с большой вероятностью не пройдет отбор, если возникнут проблемы в интерфейсе или падения в процессе выполнения базовых пользовательских сценариев. Универсального рецепта приготовления идеального приложения, которое гарантированно пройдёт отбор, нет. Есть множество подходов к разработке и разные варианты построения архитектуры, но одна из составляющих успеха — позитивные пользовательские ощущения. Продукт должен создавать впечатление законченности, независимо от того, сколько в нем полезной функциональности, экранов или элементов.
CLion 2019.1: ClangFormat, подсветка кода через Clangd, memory view, начальная поддержка микроконтроллеров
У команды CLion множество отличных новостей — питерская часть команды вместе с другими коллегами успешно перебралась в новый офис, к нам присоединились новые классные разработчики, а главное, мы буквально на днях выпустили первое большое обновление в этом году, CLion 2019.1!
Работа в новой версии шла сразу по нескольким фронтам:
- Усовершенствования поддержки языка C++: подсветка кода через Clangd, улучшения рефакторингов Extract и Rename, новая проверка на то, что функцию-член класса можно объявить статической.
- Больше возможностей в настройках стиля написания кода: интеграция с ClangFormat, поддержка стилей именования переменных в C/C++, поддержка разных стилей для header guards.
- Новые возможности и улучшения отладчика: просмотр состояния памяти — Memory View — для указателей, просмотр дизассемблированного кода в случае LLDB, ускорение работы пошаговой отладки.
- CLion для микроконтроллеров, первые шаги.
- Возможность создавать Build Targets и конфигурации для запуска/отладки в CLion, которые никак не связаны с проектной моделью.
- Работа с другими языками программирования в строковых литералах в С/С++.
- Новые визуальные темы и другие платформенные возможности.

Подробнее об этих и других нововведениях читайте ниже. А чтобы попробовать новые возможности и улучшения, скачайте бесплатную 30-дневную версию CLion с нашего сайта.
Zero, one, two, Freddy's coming for you

This post continues the series of articles, which can well be called «horrors for developers». This time it will also touch upon a typical pattern of typos related to the usage of numbers 0, 1, 2. The language you're writing in doesn't really matter: it can be C, C++, C#, or Java. If you're using constants 0, 1, 2 or variables' names contain these numbers, most likely, Freddie will come to visit you at night. Go on, read and don't say we didn't warn you.
Ноль, один, два, Фредди заберёт тебя

Перед вами продолжение серии статей, которую можно озаглавить «ужасы для программистов». В этот раз речь пойдёт о типовом паттерне опечаток, связанном с использованием чисел 0, 1, 2. Неважно, пишете вы на C, C++, C# или Java. Если вы используете константы 0, 1, 2, или если эти числа содержатся в именах переменных, то, скорее всего, Фредди заглянет к вам ночью в гости. Читайте и не говорите потом, что вас не предупреждали.
Почему инженеры уровня Senior ненавидят интервью с тестовым кодингом
Представьте, что вы директор небольшой средней школы, который хочет нанять новых учителей. Поскольку у вас в штате их должно быть не более 20, вы должны убедиться, что каждый учитель, которого вы нанимаете, сможет преподавать в любом классе. Усложним пример. Недавно уволилась одна из лучших учителей с более чем 15-ти летним стажем, и которая была наставником для многих более молодых сотрудников. Кем вы сможете её заменить?
После некоторых раздумий, вы создаёте, как вам кажется, творческий подход к интервьюированию. Когда кандидат придёт на интервью, вы попросите его провести урок, взятый из учебной программы средней школы. Поскольку вы хотите убедиться в том, что кандидат хорошо подготовлен, то вы не скажете ему какой урок он должен будет преподать. Если он справляется с таким заданием, то вы делаете вывод, что он с лёгкостью сможет провести любой урок, так как он хорошо себя проявил со случайно выбранной темой.
Вы размещаете объявление о найме и, через некоторое время, несколько интересных кандидатов подают заявки. Однако, протестировать свой новый подход вы планируете на учителе, которого рекомендовал один из ваших сотрудников, который работал с ней в прошлом, как классного специалиста. Вы не верите в своё счастье, что она вообще согласилась, и думаете, что она будет идеальным подопытным кроликом в вашем эксперименте. Вы связываетесь с ней, чтобы назначить день собеседования и рассказываете её о своём новом подходе, чтобы дать ей возможность подготовиться.
Наконец, наступает день интервью и ваш кандидат появляется в школе. Вы замечаете, что она немного нервничает, что странно, потому что она опытный кандидат и её резюме безупречно. Вы решаете не думать об этом и проводите её в один из ваших классов, чтобы начать собеседование. “Мне бы хотелось, чтобы вы преподали мне урок по теории чисел”. В этот момент её лицо помрачнело. Дело в том, что она не преподавала в 8-м классе вот уже более чем 10 лет. Но вы об этом не были осведомлены. Как профессионал, она пошла к доске и начала урок. Она рассказывает о множителях чисел и о том, как определить делится ли число на 2, 5 и 10. Но видно, как её трудно. Вы просите её рассказать о GСF и LCM, но она просит уточнить, что означают эти аббревиатуры. Вы расцениваете это как дурной знак и объясняете, что имели в виду “наибольший общий делитель” и “наименьшее общее кратное”. В этот момент вы замечаете, что её уверенность в себе поколебалась и чувствуете раздражение в её голосе.