# coding style Published articles for coding style. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Libreboot Build System Audit 4 DevFeed: [Libreboot Build System Audit 4]() Original publisher: [Read original article]() Author: Leah Rowe Published: 2026-09-17T04:32:50.666044Z Content type: article Language: en Sources: [News about Libreboot releases and development]() Topics: [audit](), [Shell](), [Code](), [coding style](), [Open Source]() Tags: [article](), [audit](), [bios](), [build](), [build-system](), [canoeboot](), [coding-style](), [complexity](), [coreboot](), [free-software](), [libre](), [libreboot](), [opensource](), [patches](), [uefi]() ### AI overview This article reviews the fourth audit of the Libreboot build system, lbmk, covering code cleanup, generalization, new features, and bug fixes. It reports a reduction from 1,744 to 1,618 shell-script SLOC and a corresponding 7.22% decrease in complexity, while functionality increased. ### Source excerpt Article: Libreboot Build System Audit 4 Web link: https://libreboot.org/news/audit4.html ## Cargo Cult Programming: Applying Patterns Without Understanding Them DevFeed: [Cargo Cult Programming: Applying Patterns Without Understanding Them]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-10-18T16:37:23Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Programming](), [Refactoring](), [Code]() Tags: [code](), [coding](), [coding-style](), [function](), [team]() ### AI overview The article defines cargo cult programming as applying design patterns or coding styles without understanding their rationale. It argues that making code smaller is not automatically better and that cohesive, readable functions can be preferable to terse or fragmented code. ### Source excerpt If you're a software engineer long enough, you will meet some gray beards that throw out-of-left-field phrases to convey software wisdom. For example, you should know if you're yak-shaving or bike-shedding, and when that's even a good thing. A recent HN article1 reminded me of another nugget - Cargo Culting (or Cargo Cult Programming). Definition ### Cargo Culting: ritualizing a process without understanding it. In the context of programming: practice of applying a design pattern or coding style blindly without understanding the reasons behind it Example ### I'm going to take this opportunity to air one of my personal cargo-culting pet peeves, sure to kick up another storm: Making everything small. When I get PR feedback saying "this class is too long, split this!", I get ready to launch into a tirade: you're confusing small with logically small - ritualizing line count without understanding cohesion. You can make code small by being terse: removing whitespace, cramming logic into one-liners, using clever shorthand.2 But you've just made it harder to read. A function that does one cohesive thing beats multiple smaller functions scattered across files. Etymology ### As the parable goes, after the end of the Second World War, indigenous tribes believed that air delivery of cargo would resume if they carried out the proper rituals, such as building runways, lighting fires next to them, and wearing headphones carved from wood while sitting in fabricated control towers. While on the surface amusing, there's sadness if you dig into the history and contributing factors (value dominance, language & security barriers). I don't think that's reason to avoid the term altogether. We as humans sometimes have to embrace our dark history, acknowledge our wrongs and build kindness in our hearts. We cannot change our past, but we can change our present and future. The next time someone on your team ritualizes a pattern without understanding it, you'll know what to call it. Who comes ## Engineering Audits for ISO 13485 Medical Device Software Quality Management Systems DevFeed: [Engineering Audits for ISO 13485 Medical Device Software Quality Management Systems]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-08-18T20:21:35Z Content type: article Language: en Sources: [Anna J McDougall]() Topics: [audit](), [Requirements](), [Development](), [Software](), [systems]() Tags: [audit](), [coding-style](), [compliance](), [engineering](), [engineering-management](), [iso](), [iso-13485-standard](), [lifecycle](), [management](), [medical-devices](), [processes](), [quality](), [regulatory](), [requirements](), [review](), [risk-management](), [safety](), [software](), [software-engineering](), [systems]() ### AI overview This case study explains what an engineering audit involves under ISO 13485 for medical device software. It covers Quality Management System documentation, lifecycle management, patient safety, risk management, regulatory requirements, and the author's experience updating engineering compliance documents. ### Source excerpt What is an Engineering Audit Like? An ISO 13485 Medical Device Engineering QMS Case StudyI think I found my new look. If there's one thing that gets me fired up, it's a good ol'-fashioned audit! ... Said nobody ever. Sadly, audits are a part of the business world that tend not to be fun. However, they also serve an important purpose, and are part of the transition from the "fun team lead" style of management into the "business leader" role is coming to grips with the unsexy stuff. As part of my role at HelloBetter, I was tasked with leading engineering compliance and reporting for ISO 13485, an internationally recognised standard for Quality Management Systems (QMS) specifically for medical device manufacturers, within the broader context of the EU Medical Device Regulation (MDR). For those who aren't familiar with what an audit of this kind involves, the simple version is this: Certain requirements exist as part of the standard, not just about how to effectively create and maintain software, but also how to document that compliance. This documentation is referred to as the Quality Management System (QMS), which as the name implies serves as documentation for how you maintain quality as per the ISO. The ISO isn't only about software, but software is part of "Lifecycle Management", tracking how a medical device (in this case) goes from design and development to distribution and surveillance. A company required to meet the ISO should therefore create and follow a system that ticks all the boxes for things like patient safety, risk management, and any additional regulatory hurdles. Typically once a year, an auditor is hired to enter the company and review the documentation alongside representatives from the company who guide them through the QMS. Additionally, individuals (like me!) are pulled from different parts of the company to talk through their processes and documentation, and to show any examples that may be relevant. My Experience with Engineering Compliance for ## Refreshed Nuxt ESLint Integrations DevFeed: [Refreshed Nuxt ESLint Integrations]() Original publisher: [Read original article]() Published: 2024-04-10T00:00:00Z Content type: article Language: en Sources: [The Nuxt Blog]() Topics: [ESLint](), [Nuxt.js](), [configuration](), [Developer experience]() Tags: [article](), [coding-style](), [config](), [developer-experience](), [documentation](), [eslint](), [legacy](), [maintenance](), [monorepo](), [nuxt]() ### AI overview Nuxt has refreshed its ESLint integrations to support ESLint v9 and its flat configuration format. The update consolidates ESLint-related packages into a monorepo, introduces an all-in-one module for Nuxt 3, and provides new documentation and package comparisons. ### Source excerpt We revamped our ESLint integrations to support ESLint v9 with the flat config, as well as a new module with many more capabilities. ## Importance of writing in the engineering industry DevFeed: [Importance of writing in the engineering industry]() Original publisher: [Read original article]() Author: TheAnkurTyagi Published: 2024-02-19T12:12:49Z Content type: opinion Language: en Sources: [ByteSizedBets]() Topics: [Software Engineering](), [Specifications](), [coding style](), [Slack]() Tags: [coding-style](), [engineering](), [slack](), [software-engineering](), [specifications]() ### AI overview This article argues that writing is essential in software engineering because teams rely on written communication for alignment, code reviews, technical specifications, and code. It recommends prioritizing product specifications, technical specifications, and coding style guides, particularly in mid-sized organizations. ### Source excerpt Spoiler: It's very important! ## Using Fleet 1.19's AI Assistant to Convert Kotlin Between Imperative and Functional Styles DevFeed: [Using Fleet 1.19's AI Assistant to Convert Kotlin Between Imperative and Functional Styles]() Original publisher: [Read original article]() Published: 2023-06-10T13:12:44Z Content type: article Language: en Sources: [maiatoday]() Topics: [coding style](), [Kotlin](), [Functional programming](), [Artificial Intelligence](), [coding](), [Code](), [Advent of Code]() Tags: [advent-of-code](), [ai](), [ai-assistant](), [code](), [coding-style](), [doggerel](), [fleet](), [functional](), [functional-programming](), [imperative](), [kotlin](), [word-games]() ### AI overview The article experiments with Fleet 1.19's integrated AI assistant by converting Kotlin code for the Advent of Code 2022 Day 10 puzzle between imperative and functional styles, comparing the results, and generating poetry. ### Source excerpt Once upon a time I admit. I have a penchant for word games and weird segues. So I will tell you what this post is about off the bat. You can skip to the code, I won't be offended. Fleet 1.19 was released this week with an integrated AI assistant. I took it for a spin and used it to convert Kotlin code from imperative style to functional and back again. I used some Kotlin code, which solves the Advent of Code 2022 Day 10 puzzle. I had written the solution in two styles and I had the AI assistant do the same conversion and compared the code. And then I played around and generated some poetry. Follow links at your peril, there are rabbit holes, it might make you late or change the size of your free time. Segue the first of many Oh you are still here! You didn't jump to the code starts here section? Why am I doing this? A long time ago, I read a lot of Lewis Caroll, Alice in Wonderland. In one scene Alice talks to the Mock Turtle. He sings a song about sea creatures dancing. When the first language translators appeared on the scene, Altavisa babelfish or perhaps it was the early Google Translate, I converted passages from Alice in Wonderland to French and then back again to see what the machines could do. The Mock Turtle was transformed into an Imitation Tortoise. In this way the reference to the original mock turtle soup was lost in translation. In a roundabout way I was wondering what would be uncovered or lost if I used the AI assistant for some translations in coding style. Couplets of doggerel My trusty and non emotional assistant had no opinion on Lewis Caroll but it made this for me. A definition of functional programming style in rhyming couplets: Functional programming's way, treats functions as the play. Immutable states they use, side effects they refuse. Declarative code is their choice, with functions, they rejoice. Nested functions map, filter, reduce, a clean, elegant code they produce. Compare this with the imperative version: Imperative code, step by st ## 3 Things We Learned When Switching to TypeScript DevFeed: [3 Things We Learned When Switching to TypeScript]() Original publisher: [Read original article]() Author: Tom Bartel Published: 2022-08-01T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [TypeScript](), [migration](), [Next.js](), [Web Development]() Tags: [coding-style](), [frontend](), [generics](), [migration](), [next-js](), [php](), [switching](), [type-safety](), [typescript]() ### AI overview Trivago describes lessons from switching its core product web application from a PHP/JavaScript stack to Next.js and TypeScript. The article discusses initial resistance, adapting coding practices, increased confidence when modifying unfamiliar code, and TypeScript's limits compared with Java or C# type safety. ### Source excerpt With the rewrite of our core product web application, we moved from a PHP/JavaScript tech stack to a Next.js stack. One of ... ## 3 Guidelines to Reduce Implementation Flaws DevFeed: [3 Guidelines to Reduce Implementation Flaws]() Original publisher: [Read original article]() Author: Pratik Shekhar Published: 2021-09-03T17:06:05Z Content type: opinion Language: en Sources: [Groupon Engineering -- Medium]() Topics: [Code quality](), [coding](), [implementation](), [Testing](), [Unit testing]() Tags: [code-quality](), [coding](), [coding-style](), [function](), [google](), [implement](), [software-development](), [team](), [tech](), [test](), [testing](), [unit-testing]() ### AI overview The article presents coding guidelines intended to reduce implementation flaws. It emphasizes code quality, readability, team practices, breaking functions into smaller single-purpose units, and making code easier to test and reuse. ### Source excerpt 3 Rules/Guidelines to Reduce Implementation Flaws When I hear the word "rule", I think back to grade school. "Be quiet when the teacher is talking." "No interrupting, you must raise your hand with a question." But what makes this different than following a set of guidelines? There was always that one kid who never listened to the rules. In coding, we may talk about rules, whereas in reality, we're following some sort of guideline. Think of guidelines as a scene from the Ghostbusters movie when Bill Murray told Sigourney Weaver that he never sleeps with a possessed woman. Then she kissed him and he said, "Actually, this is more of a guideline than a rule." A standard guideline is important because it helps improve the existing code quality, a guideline also makes it more readable and also somewhere sets the team culture. Over the last few years of gaining more experience in coding, rules have changed into guidelines; however, there are three top guidelines I always follow. After being curious if other colleagues follow any specific coding guidelines, I reached out to several within Groupon and companies like Google, Morgan Stanley, Apple, Lutron, L Brands, Capitol One, GoPuff, and Vertex Inc. Specifically, I asked if they follow any guidelines that reduce implementation flaws. To not much surprise, we all follow similar guidelines. Take a moment and ask yourself, do you have any specific rules or guidelines? We may all have similar guidelines that we follow, mine are listed below- Guideline 1 -> Break down your functions My first rule is merely following the single responsibility principle. A function should be responsible for doing one specific thing. If a function has too many responsibilities, then it should be broken down into multiple smaller functions. Its logic is limited in scope, which makes it easier to implement and test its end-to-end functionality. A friend of mine once said that "If the function you end up unit testing requires tests for multiple separat ## Kotlin string templates, destructuring declarations, and sealed classes DevFeed: [Kotlin string templates, destructuring declarations, and sealed classes]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2021-01-01T09:23:42Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Kotlin](), [coding](), [coding style]() Tags: [coding](), [coding-style](), [destructuring](), [kotlin](), [kotlin-beginner](), [programming-languages](), [programming-tips](), [sealed-class]() ### AI overview A Kotlin tutorial covering string templates, raw multiline strings, destructuring declarations, and sealed classes. It notes that destructuring can be risky when a class member order changes. ### Source excerpt Part 2 of 'Cooking Tasty Code'. Dive deeper into Kotlin features like delegation, operator overloading, and more to enhance your coding style. ## Name It, and They Will Come DevFeed: [Name It, and They Will Come]() Original publisher: [Read original article]() Published: 2019-03-25T00:00:00Z Content type: opinion Language: en Sources: [Dan Abramov]() Topics: [Open Source](), [GitHub](), [coding style](), [Programming]() Tags: [ci](), [coding-style](), [documentation](), [github](), [open-source](), [programming-languages]() ### AI overview This essay describes the excitement and uncertainty of developing and launching an open-source project. It concludes with a disappointing response: public discussion focuses on indentation in a README example rather than the project's central idea. ### Source excerpt A change starts with a story. ## GSOC Project TSE Week 5 DevFeed: [GSOC Project TSE Week 5]() Original publisher: [Read original article]() Published: 2017-07-06T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Refactoring](), [coding style](), [Code](), [ui]() Tags: [code](), [code-reviews](), [coding-style](), [free](), [gsoc](), [open-source](), [os](), [react](), [reactos](), [refactoring](), [win32](), [winapi]() ### AI overview A week-five GSoC project update for ReactOS describes code reviews conducted through Crucible, continued work on QuickLaunch menus, and implementation of context-menu options such as views and showing text. The author also reports refactoring, code fixes, removal of unnecessary interfaces, and menu localization work. ### Source excerpt Hey there! 0/ Last time you must have seen some snapshots of where the QuickLaunch has reached. Seeing the UI and some functionalities in the snaps must have given you a feeling that it's complete and finished. But, Nah... a lot of work is left, besides debugging so that Dr. Watson would finally be free of his postmortems!! XP Coming straight to the point, this week the best thing was about 'Code Reviews'. ## Effective Coding Standards DevFeed: [Effective Coding Standards]() Original publisher: [Read original article]() Author: umer Published: 2016-05-22T00:00:00Z Content type: opinion Language: en Sources: [Code Ahoy - Articles]() Topics: [coding](), [Programming](), [Software](), [Code review](), [Linux]() Tags: [best-practices](), [code-review](), [coding-style](), [developer](), [programming](), [software]() ### AI overview This opinion article argues that coding standards are useful for consistency and maintainability, but warns that overly personal, rigid, or undocumented rules can damage developer morale and make code reviews unproductive. ### Source excerpt Coding standards are a set of guidelines, best practices, programming styles and conventions that developers adhere to when writing source code for a project. All big software companies have them. Here are few guidelines from the 'Linux kernel coding style': a. Tabs are 8 characters, and thus indentations are also 8 characters. b. The limit on the length of lines is 80 columns and this is a strongly preferred limit. c. The preferred form for allocating a zeroed array is the following: p = kcalloc(n, sizeof(...), ...); Both forms check for overflow on the allocation size n * sizeof(...), and return NULL if that occurred. Recently, I came across a blog post from Richard Rodger. In 'Why I Have Given Up on Coding Standards', he writes: Every developer knows you should have a one, exact, coding standard in your company. Every developer also knows you have to fight to get your rules into the company standard. Every developer secretly despairs when starting a new job, afraid of the crazy coding standard some power-mad architect has dictated. It's better to throw coding standards out and allow free expression. The small win you get from increased conformity does not move the needle. Coding standards are technical ass-covering. Oh boy. While I disagree with Richard that coding standards should be abandoned, I share his pain. I briefly worked with a nut job of a "senior developer" who came in as the lead for a project we'd been working on for 6 months. He was an academic who had just finished his PhD and had little experience working on real world projects. He spent first couple of weeks writing "coding standards" in total isolation like he was some kind of a God and we were lowly beings who just weren't good enough. His coding standards document was full of his personal opinions and promoted some insane form of coding style. The control freak demanded that we update the source code we had already written to reflect his standards. I have never witnessed team morale hit rock bot ## git pre-commit hook for code beautification DevFeed: [git pre-commit hook for code beautification]() Original publisher: [Read original article]() Author: Ramon Published: 2016-01-30T20:22:19Z Content type: tutorial Language: en Sources: [Ramon Fried]() Topics: [Git](), [Linux](), [Script](), [Kernel](), [Command-line interface]() Tags: [artistic-style](), [astyle](), [code-beautification](), [coding-style](), [command-line](), [git](), [git-commit](), [git-hook](), [how-to](), [improvements](), [kernel](), [linux](), [linux-kernel](), [script](), [uncategorized](), [workflow]() ### AI overview A tutorial on using a Git pre-commit hook to automate code beautification. The hook runs astyle on files included in a commit, helping apply formatting rules such as spacing and indentation; the article also discusses Linux user-space and kernel coding styles and the checkpatch.pl script. ### Source excerpt Hi. In this post I will share a git pre-commit hook I created for aiding with code beautification. In Linux, I work in two different coding styles: User space and Kernel. The Linux kernel has a very specific coding style and every commit to kernel must adhere to that style. The Linux kernel provides a [...] ## Java 8 workshop at Finn.no DevFeed: [Java 8 workshop at Finn.no]() Original publisher: [Read original article]() Author: Sjur Millidahl Published: 2015-02-16T07:50:16Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Java](), [coding style](), [Code](), [exceptions]() Tags: [coding-style](), [exceptions](), [java](), [lambda](), [language](), [optional](), [stream](), [workshop]() ### AI overview This article describes a two-part workshop at Finn.no on adopting Java 8's functional programming features. It covers streams and lambdas, then Optional and an in-house Either type for handling absent values and exceptions. ### Source excerpt Pondering on the right lambda for the job With Java 8 comes a whole new set of language features. It even challenges the imperative coding-style of the Java programmer. Java is a core language in Finn.no. More and more of our java-modules are being built with Java 8, adopting new features of the language. A workshop was warranted, with the goal of bringing every developer up to speed on the functional paradigm of Java 8. In Finn.no, we want programmers to do stuff like this db.fetchLastDayAds() .stream() .filter(ad -> "bap-webstore".equals(ad.getAdType())) .flatMap(ad -> ad.getContacts().stream()) .distinct() .flatMap(per -> Optional.ofNullable(contact.getEmail()).map(Stream::of) .orElseGet(Stream::empty)) .peek(contact -> LOG.trace("Sending notification to "+per)) .forEach(this::sendNotification); While avoiding stuff like this IntStream.iterate(0, i -> (i + 1) % 2) .parallel() .distinct() .limit(10) .forEach(System.out::println); (Locking up all cores on a CPU is bad, and should only be done when the machine is right about to become self-aware and turn against you.) Several lambda-arrows pointing in the right direction here We split the workshop into two half days. The first day was dedicated to streams and lambdas. Everyone seemed keen on getting those tests green (a rhyme!). Day 2 we raised the bar with Optional and our in-house version of Either. With these structures, much more code can be written functionally in a world where values might not exist (be null), and things may go wrong (throw exceptions). We need power.. lots of power! Both the word "monad" and the phrase "monadic domain" was uttered several times, but we still saw very few making the swoooosh-sound while flying a hand over their head (the internationally recognized sign of communicating that a topic is beyond mental capacity). This might mean that the timing was good, and developers are interested in the new features of Java 8. You may checkout the project and do the tasks yourself, by mak ## Improving Frontend Code Quality and Workflow DevFeed: [Improving Frontend Code Quality and Workflow]() Original publisher: [Read original article]() Author: Wordbitly Published: 2012-12-11T18:45:27Z Content type: tutorial Language: en Sources: [Bitly]() Topics: [Front end](), [Code quality](), [JavaScript](), [Refactoring](), [modules](), [engineering-culture]() Tags: [code-quality](), [code-review](), [coding](), [coding-style](), [consistency](), [frontend](), [maintainability](), [refactoring]() ### AI overview A Bitly frontend engineer describes improving code quality and workflow by introducing shared JavaScript style conventions, evaluating tools and libraries, and adopting CoffeeScript for new frontend code. The article explains how consistent patterns can improve code readability, onboarding, and maintainability. ### Source excerpt When I started at Bitly as a Frontend Engineer, we were about to launch the new bitly. It was exciting to be so close to a product launch and we were cranking out lots of code each day. It took me a few days to get my bearings in the sprawling codebase and I saw lots of opportunity for refactoring, cleanup, and style normalization as well as some architectural concepts we weren't leveraging. Product launch mode kept us from doing house keeping for the next few months after we released the new product as we collected feedback and iterated on several designs/functionalities. Once we had a chance to take a step back and regroup, I saw that we could be more productive if we invested in a common JavaScript style (both syntax and module level patterns) and re-evaluated which libraries we were leveraging to build the site. When we decided the next feature work would be on save/share modal dialogs, I used this as an opportunity to evaluate my new picks for tools and libraries. The result was a success and allowed us to adopt the new tools and libraries for all new features (see Easily Save and Share the Links You Love). Keep reading to see what tools we ended up using to make us more productive! Coding style guidelines If you've seen frontend JavaScript codebases older than six months with two or more developers working on them, you've seen how hard it is to enforce style. The goal of a style guide (and code conventions in general) is to reduce the amount of friction when switching between different modules in a codebase and increase the consistency and readability of code. If every module follows the same patterns, you can easily get your bearings in code written by your coworkers. Every team should have a common style that is enforced in code review and ideally written in a document that can be referred to for new hires. For JavaScript at Bitly, we mostly use the Google Style Guide without the JSDoc and with a variation that non-method variables are lowercase_with_undersc