#code_style — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #code_style, aggregated by home.social.
-
Очень много букв… Или кейс по специфической настройке рабочего окружения
Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.
https://habr.com/ru/articles/1038372/
#когнитивная_нагрузка #VSCode #clangformat #clangtidy #code_style #рабочее_окружение #настройка_ide #продуктивность #нейроразнообразие
-
Очень много букв… Или кейс по специфической настройке рабочего окружения
Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.
https://habr.com/ru/articles/1038372/
#когнитивная_нагрузка #VSCode #clangformat #clangtidy #code_style #рабочее_окружение #настройка_ide #продуктивность #нейроразнообразие
-
Очень много букв… Или кейс по специфической настройке рабочего окружения
Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.
https://habr.com/ru/articles/1038372/
#когнитивная_нагрузка #VSCode #clangformat #clangtidy #code_style #рабочее_окружение #настройка_ide #продуктивность #нейроразнообразие
-
Очень много букв… Или кейс по специфической настройке рабочего окружения
Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.
https://habr.com/ru/articles/1038372/
#когнитивная_нагрузка #VSCode #clangformat #clangtidy #code_style #рабочее_окружение #настройка_ide #продуктивность #нейроразнообразие
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми
Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.
https://habr.com/ru/articles/1001496/
#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style
-
10 удобных конструкций Python
Разбираем 10 удобных конструкций Python, которые помогают писать код короче и понятнее: list и dict comprehension, zip, enumerate, f-строки, Pathlib и другие полезные приёмы. Особенно полезно начинающим разработчикам.
https://habr.com/ru/articles/932344/
#python #programming #программирование #однострочники #code_style #начинающим
-
10 удобных конструкций Python
Разбираем 10 удобных конструкций Python, которые помогают писать код короче и понятнее: list и dict comprehension, zip, enumerate, f-строки, Pathlib и другие полезные приёмы. Особенно полезно начинающим разработчикам.
https://habr.com/ru/articles/932344/
#python #programming #программирование #однострочники #code_style #начинающим
-
10 удобных конструкций Python
Разбираем 10 удобных конструкций Python, которые помогают писать код короче и понятнее: list и dict comprehension, zip, enumerate, f-строки, Pathlib и другие полезные приёмы. Особенно полезно начинающим разработчикам.
https://habr.com/ru/articles/932344/
#python #programming #программирование #однострочники #code_style #начинающим
-
10 удобных конструкций Python
Разбираем 10 удобных конструкций Python, которые помогают писать код короче и понятнее: list и dict comprehension, zip, enumerate, f-строки, Pathlib и другие полезные приёмы. Особенно полезно начинающим разработчикам.
https://habr.com/ru/articles/932344/
#python #programming #программирование #однострочники #code_style #начинающим
-
Автоматизация проверки стиля кода с помощью KtLint в Android проекте
Современная разработка программного обеспечения требует не только написания функционального кода, но и обеспечения его качества, надежности и безопасности. Для обеспечения этого во многих командах по-прежнему существует Code Review. По моему мнению в 90% случаев это абсолютно бесполезная трата времени и сил разработчиков команды. Code Review это рудимент, который изжил себя. Я не утверждаю, что Code Review должен исчезнуть - принцип и подход должны измениться. Ручная организация Code Review ведет к деградации продуктивности и взаимоотношений внутри команды. Очень часто Code Review превращается в способ самоутверждения, эмоциональной разрядке одного из участников команды за счет других. Комментарии часто бывают противоречивыми и контр продуктивными. Как этого избежать? Ответ – полностью автоматизировать этот процесс. Одним из ключевых инструментов для достижения этой цели является статистический анализ кода - метод автоматизированной проверки исходного кода без его выполнения. Я всю свою практику участвовал в командах, где Code Review было ручным и каждый участник команды ставил approve, либо оставлял комментарий. Думаю, так происходит и сейчас во многих командах. Качество такого Review низкое и трудно быть по-настоящему объективным. Мне повезло участвовать в большом стартапе и начать проект самостоятельно. И в моем проекте я решил покончить с Code Review. Что мне было необходимо? Нужен был инструмент который бы приводил код к единому стилю и избавил меня и других участников команды от необходимости проверять стиль кода. Сюда входит правила расстановки новых строк, именования методов, отступы и тд. Необходимо чтоб инструмент подсвечивал места где стиль не соблюдается и исправлял автоматически такие места.
https://habr.com/ru/articles/914250/
#kotlin #code_style #static_analysis #android #intellijidea #command #management #clean_code
-
Автоматизация проверки стиля кода с помощью KtLint в Android проекте
Современная разработка программного обеспечения требует не только написания функционального кода, но и обеспечения его качества, надежности и безопасности. Для обеспечения этого во многих командах по-прежнему существует Code Review. По моему мнению в 90% случаев это абсолютно бесполезная трата времени и сил разработчиков команды. Code Review это рудимент, который изжил себя. Я не утверждаю, что Code Review должен исчезнуть - принцип и подход должны измениться. Ручная организация Code Review ведет к деградации продуктивности и взаимоотношений внутри команды. Очень часто Code Review превращается в способ самоутверждения, эмоциональной разрядке одного из участников команды за счет других. Комментарии часто бывают противоречивыми и контр продуктивными. Как этого избежать? Ответ – полностью автоматизировать этот процесс. Одним из ключевых инструментов для достижения этой цели является статистический анализ кода - метод автоматизированной проверки исходного кода без его выполнения. Я всю свою практику участвовал в командах, где Code Review было ручным и каждый участник команды ставил approve, либо оставлял комментарий. Думаю, так происходит и сейчас во многих командах. Качество такого Review низкое и трудно быть по-настоящему объективным. Мне повезло участвовать в большом стартапе и начать проект самостоятельно. И в моем проекте я решил покончить с Code Review. Что мне было необходимо? Нужен был инструмент который бы приводил код к единому стилю и избавил меня и других участников команды от необходимости проверять стиль кода. Сюда входит правила расстановки новых строк, именования методов, отступы и тд. Необходимо чтоб инструмент подсвечивал места где стиль не соблюдается и исправлял автоматически такие места.
https://habr.com/ru/articles/914250/
#kotlin #code_style #static_analysis #android #intellijidea #command #management #clean_code
-
Автоматизация проверки стиля кода с помощью KtLint в Android проекте
Современная разработка программного обеспечения требует не только написания функционального кода, но и обеспечения его качества, надежности и безопасности. Для обеспечения этого во многих командах по-прежнему существует Code Review. По моему мнению в 90% случаев это абсолютно бесполезная трата времени и сил разработчиков команды. Code Review это рудимент, который изжил себя. Я не утверждаю, что Code Review должен исчезнуть - принцип и подход должны измениться. Ручная организация Code Review ведет к деградации продуктивности и взаимоотношений внутри команды. Очень часто Code Review превращается в способ самоутверждения, эмоциональной разрядке одного из участников команды за счет других. Комментарии часто бывают противоречивыми и контр продуктивными. Как этого избежать? Ответ – полностью автоматизировать этот процесс. Одним из ключевых инструментов для достижения этой цели является статистический анализ кода - метод автоматизированной проверки исходного кода без его выполнения. Я всю свою практику участвовал в командах, где Code Review было ручным и каждый участник команды ставил approve, либо оставлял комментарий. Думаю, так происходит и сейчас во многих командах. Качество такого Review низкое и трудно быть по-настоящему объективным. Мне повезло участвовать в большом стартапе и начать проект самостоятельно. И в моем проекте я решил покончить с Code Review. Что мне было необходимо? Нужен был инструмент который бы приводил код к единому стилю и избавил меня и других участников команды от необходимости проверять стиль кода. Сюда входит правила расстановки новых строк, именования методов, отступы и тд. Необходимо чтоб инструмент подсвечивал места где стиль не соблюдается и исправлял автоматически такие места.
https://habr.com/ru/articles/914250/
#kotlin #code_style #static_analysis #android #intellijidea #command #management #clean_code
-
Автоматизация проверки стиля кода с помощью KtLint в Android проекте
Современная разработка программного обеспечения требует не только написания функционального кода, но и обеспечения его качества, надежности и безопасности. Для обеспечения этого во многих командах по-прежнему существует Code Review. По моему мнению в 90% случаев это абсолютно бесполезная трата времени и сил разработчиков команды. Code Review это рудимент, который изжил себя. Я не утверждаю, что Code Review должен исчезнуть - принцип и подход должны измениться. Ручная организация Code Review ведет к деградации продуктивности и взаимоотношений внутри команды. Очень часто Code Review превращается в способ самоутверждения, эмоциональной разрядке одного из участников команды за счет других. Комментарии часто бывают противоречивыми и контр продуктивными. Как этого избежать? Ответ – полностью автоматизировать этот процесс. Одним из ключевых инструментов для достижения этой цели является статистический анализ кода - метод автоматизированной проверки исходного кода без его выполнения. Я всю свою практику участвовал в командах, где Code Review было ручным и каждый участник команды ставил approve, либо оставлял комментарий. Думаю, так происходит и сейчас во многих командах. Качество такого Review низкое и трудно быть по-настоящему объективным. Мне повезло участвовать в большом стартапе и начать проект самостоятельно. И в моем проекте я решил покончить с Code Review. Что мне было необходимо? Нужен был инструмент который бы приводил код к единому стилю и избавил меня и других участников команды от необходимости проверять стиль кода. Сюда входит правила расстановки новых строк, именования методов, отступы и тд. Необходимо чтоб инструмент подсвечивал места где стиль не соблюдается и исправлял автоматически такие места.
https://habr.com/ru/articles/914250/
#kotlin #code_style #static_analysis #android #intellijidea #command #management #clean_code
-
Чистый код — красивая архитектура. А работает ли это?
Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг. Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать. Видели те горящие глаза джунов-зумеров при приеме на работу, думаю в них можно прочитать: «ваш код кривой, пустите меня в прод и сделаю все как надо..» и начинает строить собственные «идеальные» архитектуры. Так что эстетика кода — это не пунктик перфекциониста, это прагматизм, и код нужно писать так, чтобы после него следующий разработчик ставил вам свечку в мыслях. Давайте разберём, как превратить кошмар в конфетку — детали внутри.
https://habr.com/ru/companies/ruvds/articles/902996/
#программирование #код #дизайн_кода #архитектура_ПО #code_style #developer_experience #ruvds_статьи
-
Чистый код — красивая архитектура. А работает ли это?
Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг. Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать. Видели те горящие глаза джунов-зумеров при приеме на работу, думаю в них можно прочитать: «ваш код кривой, пустите меня в прод и сделаю все как надо..» и начинает строить собственные «идеальные» архитектуры. Так что эстетика кода — это не пунктик перфекциониста, это прагматизм, и код нужно писать так, чтобы после него следующий разработчик ставил вам свечку в мыслях. Давайте разберём, как превратить кошмар в конфетку — детали внутри.
https://habr.com/ru/companies/ruvds/articles/902996/
#программирование #код #дизайн_кода #архитектура_ПО #code_style #developer_experience #ruvds_статьи
-
Чистый код — красивая архитектура. А работает ли это?
Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг. Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать. Видели те горящие глаза джунов-зумеров при приеме на работу, думаю в них можно прочитать: «ваш код кривой, пустите меня в прод и сделаю все как надо..» и начинает строить собственные «идеальные» архитектуры. Так что эстетика кода — это не пунктик перфекциониста, это прагматизм, и код нужно писать так, чтобы после него следующий разработчик ставил вам свечку в мыслях. Давайте разберём, как превратить кошмар в конфетку — детали внутри.
https://habr.com/ru/companies/ruvds/articles/902996/
#программирование #код #дизайн_кода #архитектура_ПО #code_style #developer_experience #ruvds_статьи
-
Чистый код — красивая архитектура. А работает ли это?
Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг. Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать. Видели те горящие глаза джунов-зумеров при приеме на работу, думаю в них можно прочитать: «ваш код кривой, пустите меня в прод и сделаю все как надо..» и начинает строить собственные «идеальные» архитектуры. Так что эстетика кода — это не пунктик перфекциониста, это прагматизм, и код нужно писать так, чтобы после него следующий разработчик ставил вам свечку в мыслях. Давайте разберём, как превратить кошмар в конфетку — детали внутри.
https://habr.com/ru/companies/ruvds/articles/902996/
#программирование #код #дизайн_кода #архитектура_ПО #code_style #developer_experience #ruvds_статьи
-
Мне всё равно, какой у вас код-стайл
Привет, Хабр. Меня зовут Рогатнев Сергей. Я работаю в Контуре ведущим разработчиком уже более 7 лет. За это время я поработал как минимум над десятью разными проектами в разных командах. Это были и проекты с историей на 10 лет, и стартапы, делающие свои первые шаги. Где-то я был всего 2-3 месяца, а где-то задерживался на пару лет. Такой формат работы позволил мне увидеть совершенно разные подходы к работе и написанию кода. За это время я адаптировался к переходам и смене команд, но мой собственный code style практически исчез, потому что нет двух команд с одинаковым стилем. В этой статье я хочу показать вам примеры таких холиваров, которые я встретил работая над разными C#-проектами.
-
Мне всё равно, какой у вас код-стайл
Привет, Хабр. Меня зовут Рогатнев Сергей. Я работаю в Контуре ведущим разработчиком уже более 7 лет. За это время я поработал как минимум над десятью разными проектами в разных командах. Это были и проекты с историей на 10 лет, и стартапы, делающие свои первые шаги. Где-то я был всего 2-3 месяца, а где-то задерживался на пару лет. Такой формат работы позволил мне увидеть совершенно разные подходы к работе и написанию кода. За это время я адаптировался к переходам и смене команд, но мой собственный code style практически исчез, потому что нет двух команд с одинаковым стилем. В этой статье я хочу показать вам примеры таких холиваров, которые я встретил работая над разными C#-проектами.
-
Мне всё равно, какой у вас код-стайл
Привет, Хабр. Меня зовут Рогатнев Сергей. Я работаю в Контуре ведущим разработчиком уже более 7 лет. За это время я поработал как минимум над десятью разными проектами в разных командах. Это были и проекты с историей на 10 лет, и стартапы, делающие свои первые шаги. Где-то я был всего 2-3 месяца, а где-то задерживался на пару лет. Такой формат работы позволил мне увидеть совершенно разные подходы к работе и написанию кода. За это время я адаптировался к переходам и смене команд, но мой собственный code style практически исчез, потому что нет двух команд с одинаковым стилем. В этой статье я хочу показать вам примеры таких холиваров, которые я встретил работая над разными C#-проектами.
-
Мне всё равно, какой у вас код-стайл
Привет, Хабр. Меня зовут Рогатнев Сергей. Я работаю в Контуре ведущим разработчиком уже более 7 лет. За это время я поработал как минимум над десятью разными проектами в разных командах. Это были и проекты с историей на 10 лет, и стартапы, делающие свои первые шаги. Где-то я был всего 2-3 месяца, а где-то задерживался на пару лет. Такой формат работы позволил мне увидеть совершенно разные подходы к работе и написанию кода. За это время я адаптировался к переходам и смене команд, но мой собственный code style практически исчез, потому что нет двух команд с одинаковым стилем. В этой статье я хочу показать вам примеры таких холиваров, которые я встретил работая над разными C#-проектами.
-
Проверка стиля комментариев Python с помощью pre-commit
Данный инструмент появился в результате попытки сэкономить время в процессе код-ревью, когда часть усилий тратилась на исправление какие-то незначительных, но тем не менее бросающихся в глаза артефактов, связанных с форматированием комментариев. Понятно, что эта тема гораздо шире, т.к. есть различные форматы многострочных комментариев в стиле PEP 257 или Sphinx , ну а в этот линтер вошли только наиболее часто встречающиеся случаи, связанные с написанием комментариев после решетки '#', с которыми пришлось сталкиваться в работе мне лично. Линтер может быть полезен как сам по себе либо как пример того, как можно автоматизировать проверки по согласованному стилю оформления кода.
-
Проверка стиля комментариев Python с помощью pre-commit
Данный инструмент появился в результате попытки сэкономить время в процессе код-ревью, когда часть усилий тратилась на исправление какие-то незначительных, но тем не менее бросающихся в глаза артефактов, связанных с форматированием комментариев. Понятно, что эта тема гораздо шире, т.к. есть различные форматы многострочных комментариев в стиле PEP 257 или Sphinx , ну а в этот линтер вошли только наиболее часто встречающиеся случаи, связанные с написанием комментариев после решетки '#', с которыми пришлось сталкиваться в работе мне лично. Линтер может быть полезен как сам по себе либо как пример того, как можно автоматизировать проверки по согласованному стилю оформления кода.
-
Проверка стиля комментариев Python с помощью pre-commit
Данный инструмент появился в результате попытки сэкономить время в процессе код-ревью, когда часть усилий тратилась на исправление какие-то незначительных, но тем не менее бросающихся в глаза артефактов, связанных с форматированием комментариев. Понятно, что эта тема гораздо шире, т.к. есть различные форматы многострочных комментариев в стиле PEP 257 или Sphinx , ну а в этот линтер вошли только наиболее часто встречающиеся случаи, связанные с написанием комментариев после решетки '#', с которыми пришлось сталкиваться в работе мне лично. Линтер может быть полезен как сам по себе либо как пример того, как можно автоматизировать проверки по согласованному стилю оформления кода.
-
Проверка стиля комментариев Python с помощью pre-commit
Данный инструмент появился в результате попытки сэкономить время в процессе код-ревью, когда часть усилий тратилась на исправление какие-то незначительных, но тем не менее бросающихся в глаза артефактов, связанных с форматированием комментариев. Понятно, что эта тема гораздо шире, т.к. есть различные форматы многострочных комментариев в стиле PEP 257 или Sphinx , ну а в этот линтер вошли только наиболее часто встречающиеся случаи, связанные с написанием комментариев после решетки '#', с которыми пришлось сталкиваться в работе мне лично. Линтер может быть полезен как сам по себе либо как пример того, как можно автоматизировать проверки по согласованному стилю оформления кода.
-
Стилистический Анализатор: Синхронизация Объявлений и Определений static Функций
Представлена утилита проверяльщик, что последовательность определения static функций совпадает с последовательностью объявляения static функций.
-
Стилистический Анализатор: Синхронизация Объявлений и Определений static Функций
Представлена утилита проверяльщик, что последовательность определения static функций совпадает с последовательностью объявляения static функций.
-
Стилистический Анализатор: Синхронизация Объявлений и Определений static Функций
Представлена утилита проверяльщик, что последовательность определения static функций совпадает с последовательностью объявляения static функций.
-
Flutter. Стиль кода — это все
Стиль кода — это все. Это свежий взгляд на простое и сложное. Стильный, но простой код лучше, чем сложный, но не стильный. Сложный и стильный — это искусство. Разработка может быть искусством, тестирование может быть искусством. Оптимизация кода — тоже искусство. Не все придерживаются стиля, да и не у всех он есть. В коде может быть больше стиля, чем в дизайне, но не у всего кода есть стиль. Фреймворки безмерно стильные. Когда разработчик находит идеальное сочетание функциональности и читаемости в своем коде, это стильно. Люди тоже диктуют стиль. Стиль был у Роберта Мартина, у Дэвида Томаса, у Мартина Фаулера, у Эрика Эванса... Я встречал стиль в открытом исходном коде. В среде разработчиков стильных проектов куда больше, чем в каком-либо другом сообществе. Стиль — это атрибут, подход и структура. Выше – юмористическая интерпретация слов из поэмы Чарльза Буковски «Стиль». Вариативность стиля кода настолько многогранна, что не всегда удается прийти к единому мнению в пользу того или иного подхода, поэтому стиль в сегодняшнем понимании — это целая культура. Сегодня мы будем разматывать клубок лучших практик и скрытых трюков. После этого ваш код станет не просто рабочим, а настоящим произведением искусства. С учетом моего опыта работы мобильным разработчиком в TAGES, я готов поделиться своими знаниями и практиками, которые могут быть полезны для вашего проекта. Пристегнитесь потуже — мы взлетаем!
https://habr.com/ru/articles/831470/
#Flutter #Dart #mobile_development #кроссплатформенная_разработка #мобильная_разработка #best_practices #code_style #стиль_кода #лучшие_практики #flutter_mobile_development
-
Flutter. Стиль кода — это все
Стиль кода — это все. Это свежий взгляд на простое и сложное. Стильный, но простой код лучше, чем сложный, но не стильный. Сложный и стильный — это искусство. Разработка может быть искусством, тестирование может быть искусством. Оптимизация кода — тоже искусство. Не все придерживаются стиля, да и не у всех он есть. В коде может быть больше стиля, чем в дизайне, но не у всего кода есть стиль. Фреймворки безмерно стильные. Когда разработчик находит идеальное сочетание функциональности и читаемости в своем коде, это стильно. Люди тоже диктуют стиль. Стиль был у Роберта Мартина, у Дэвида Томаса, у Мартина Фаулера, у Эрика Эванса... Я встречал стиль в открытом исходном коде. В среде разработчиков стильных проектов куда больше, чем в каком-либо другом сообществе. Стиль — это атрибут, подход и структура. Выше – юмористическая интерпретация слов из поэмы Чарльза Буковски «Стиль». Вариативность стиля кода настолько многогранна, что не всегда удается прийти к единому мнению в пользу того или иного подхода, поэтому стиль в сегодняшнем понимании — это целая культура. Сегодня мы будем разматывать клубок лучших практик и скрытых трюков. После этого ваш код станет не просто рабочим, а настоящим произведением искусства. С учетом моего опыта работы мобильным разработчиком в TAGES, я готов поделиться своими знаниями и практиками, которые могут быть полезны для вашего проекта. Пристегнитесь потуже — мы взлетаем!
https://habr.com/ru/articles/831470/
#Flutter #Dart #mobile_development #кроссплатформенная_разработка #мобильная_разработка #best_practices #code_style #стиль_кода #лучшие_практики #flutter_mobile_development
-
Flutter. Стиль кода — это все
Стиль кода — это все. Это свежий взгляд на простое и сложное. Стильный, но простой код лучше, чем сложный, но не стильный. Сложный и стильный — это искусство. Разработка может быть искусством, тестирование может быть искусством. Оптимизация кода — тоже искусство. Не все придерживаются стиля, да и не у всех он есть. В коде может быть больше стиля, чем в дизайне, но не у всего кода есть стиль. Фреймворки безмерно стильные. Когда разработчик находит идеальное сочетание функциональности и читаемости в своем коде, это стильно. Люди тоже диктуют стиль. Стиль был у Роберта Мартина, у Дэвида Томаса, у Мартина Фаулера, у Эрика Эванса... Я встречал стиль в открытом исходном коде. В среде разработчиков стильных проектов куда больше, чем в каком-либо другом сообществе. Стиль — это атрибут, подход и структура. Выше – юмористическая интерпретация слов из поэмы Чарльза Буковски «Стиль». Вариативность стиля кода настолько многогранна, что не всегда удается прийти к единому мнению в пользу того или иного подхода, поэтому стиль в сегодняшнем понимании — это целая культура. Сегодня мы будем разматывать клубок лучших практик и скрытых трюков. После этого ваш код станет не просто рабочим, а настоящим произведением искусства. С учетом моего опыта работы мобильным разработчиком в TAGES, я готов поделиться своими знаниями и практиками, которые могут быть полезны для вашего проекта. Пристегнитесь потуже — мы взлетаем!
https://habr.com/ru/articles/831470/
#Flutter #Dart #mobile_development #кроссплатформенная_разработка #мобильная_разработка #best_practices #code_style #стиль_кода #лучшие_практики #flutter_mobile_development
-
Go: передача значений VS передача указателей
Go - один из немногих языков, в которых структуры можно передавать параметрами и возвращать из функций как по значению, так и по указателю. Это приводит к большей выразительности языка, но также разделяет общество разработчиков Go на два лагеря: сторонников указателей и сторонников значений. В данной статье предлагается во многом субъективное сравнение обоих способов и делается попытка убедить читателей передавать и возвращать значения в тех случаях, где это возможно.
-
Go: передача значений VS передача указателей
Go - один из немногих языков, в которых структуры можно передавать параметрами и возвращать из функций как по значению, так и по указателю. Это приводит к большей выразительности языка, но также разделяет общество разработчиков Go на два лагеря: сторонников указателей и сторонников значений. В данной статье предлагается во многом субъективное сравнение обоих способов и делается попытка убедить читателей передавать и возвращать значения в тех случаях, где это возможно.