# formatting

Formatting is the process of converting an instance of a class or structure, or an enumeration value, to a string representation, including mechanisms provided by .NET.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## CodeSOD: The Big Family

DevFeed: [CodeSOD: The Big Family](<https://devfeed.tech/articles/codesod-the-big-family-28514.md>)

Original publisher: [Read original article](<https://thedailywtf.com/articles/the-big-family>)

Author: Remy Porter

Published: 2026-08-27T06:30:00Z

Content type: opinion

Language: en

Sources: [The Daily WTF](<https://devfeed.tech/sources/the-daily-wtf.md>)

Topics: [PHP](<https://devfeed.tech/topics/php.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Code](<https://devfeed.tech/topics/code.md>), [data](<https://devfeed.tech/topics/data.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [Localization (l10n)](<https://devfeed.tech/topics/localization.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [HTML](<https://devfeed.tech/topics/html.md>), [Parsing](<https://devfeed.tech/topics/parsing.md>)

Tags: [array](<https://devfeed.tech/tags/array.md>), [code](<https://devfeed.tech/tags/code.md>), [codesod](<https://devfeed.tech/tags/codesod.md>), [fetch](<https://devfeed.tech/tags/fetch.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [html](<https://devfeed.tech/tags/html.md>), [humor](<https://devfeed.tech/tags/humor.md>), [php](<https://devfeed.tech/tags/php.md>), [programming](<https://devfeed.tech/tags/programming.md>), [sql](<https://devfeed.tech/tags/sql.md>)

### AI overview

This commentary examines a large, generalized PHP code sample that builds hierarchical output from a presumed database source. It highlights probable SQL injection risk, unused array keys, dynamic localization fields, extensive number formatting and HTML string manipulation, string-based date-time parsing, and repeated code for child and sibling records.

### Source excerpt

Some time ago, Charles shared with us some awful PHP, aka the most common sort. Today's code sample is maybe a little too big to sum up, but I'll let Charles take a crack at it. It's so bad that even analyzing and laughing at it feels impossible. But it's so bad, I couldn't not share it. I'm the only one handling all the IT-related tasks at my company, and I don't have anyone here to vent or laugh about this kind of thing with. So, I figured, why not share it here? I'm hoping it'll provide at least a little bit of catharsis or some dark humor. To make sure the confidentiality of the codebase was respected, I took the liberty of generalizing it. You might notice some inconsistencies, but that's just me trying to keep things neutral while protecting the original structure and functionality. Apologies if it looks a bit patchy - the goal was to avoid revealing any specific details or sensitive code. The whole block is north of 400 lines, and it's doing a lot. Or well, maybe it's not, as you'll see. Let's star with the outermost layer. $resm_data = $data_source->fetchData("group=" . $item_id); foreach ($resm_data as $key => $value) { // rest of the code here } We fetch data from a data source, presumably a database, passing our condition as a string, which reeks of probable SQL injection, but I don't know what library they're using. I also note they're using the key/value style of array iteration, but never actually check the key. $option_id = $value->option_id; $resm_details = $detail_source->fetch($option_id); if ($resm_details) { $label = $resm_details->{"label$lang"}; $description = $resm_details->{"description$lang"}; $category = $resm_details->category; Nice little bit of "meta" programming to get their localization working, it'll fetch labelen or labelde as needed. Definitely not a horrible, dangerous way to solve that problem. We use that again to get our currency figured out. That lets us do number formatting. So much number formatting code. if ($category == 0)

## Introducing sqlfmt: an SQL gofmt-style formatter

DevFeed: [Introducing sqlfmt: an SQL gofmt-style formatter](<https://devfeed.tech/articles/introducing-sqlfmt-an-sql-gofmt-style-formatter-34619.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2026/08/introducing-sqlfmt-an-sql-gofmt-style-formatter/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2026-08-11T12:30:37Z

Content type: release

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [SQL](<https://devfeed.tech/topics/sql.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [Go Language](<https://devfeed.tech/topics/go-language.md>), [WebAssembly](<https://devfeed.tech/topics/web-assembly.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>)

Tags: [formatting](<https://devfeed.tech/tags/formatting.md>), [go](<https://devfeed.tech/tags/go.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [sql](<https://devfeed.tech/tags/sql.md>), [tooling](<https://devfeed.tech/tags/tooling.md>), [webassembly](<https://devfeed.tech/tags/webassembly.md>)

### AI overview

The article introduces sqlfmt, a gofmt-style SQL formatter based on the author's SQL indentation conventions from The Art of PostgreSQL. It uses a single opinionated style with no configuration options, including river alignment and specific rules for keywords, commas, continuation lines, data types, and comments. The formatter is available through a CLI and a WebAssembly-based web tool.

### Source excerpt

Formatting SQL tends to bring some of the same questions again and again: should we uppercase clause keywords? should we put the separating comma at the start of a line to ease refactoring? how to align the SQL clauses with one-another? Over the years I have grown my own SQL style and didn't find tooling that would implement it. Also, I've been asked here and there if there is a tool that would replicate The Art of PostgreSQL SQL indentation style... and now there is finally a good answer to that question! sqlfmt is a gofmt-style formatter that implements my own favorite SQL indentation style. One opinionated style, no configuration knobs. Run it, commit the result, move on.

## DeveloperHub Introduces a New Editor for More Reliable Documentation Authoring

DevFeed: [DeveloperHub Introduces a New Editor for More Reliable Documentation Authoring](<https://devfeed.tech/articles/a-new-way-to-write-docs-30958.md>)

Original publisher: [Read original article](<https://developerhub.io/blog/our-all-new-editor-experience/>)

Author: Zaid Daba'een

Published: 2026-06-30T09:47:09Z

Content type: release

Language: en

Sources: [DeveloperHub.io](<https://devfeed.tech/sources/developerhub-io.md>)

Topics: [Documentation](<https://devfeed.tech/topics/documentation.md>), [Tool](<https://devfeed.tech/topics/tool.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [render](<https://devfeed.tech/topics/render.md>)

Tags: [commands](<https://devfeed.tech/tags/commands.md>), [docs](<https://devfeed.tech/tags/docs.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [editor](<https://devfeed.tech/tags/editor.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [features](<https://devfeed.tech/tags/features.md>), [google](<https://devfeed.tech/tags/google.md>), [image](<https://devfeed.tech/tags/image.md>), [inside](<https://devfeed.tech/tags/inside.md>), [model](<https://devfeed.tech/tags/model.md>)

### AI overview

DeveloperHub has rebuilt its editor around a single document model. The new editor is designed to preserve saved formatting, improve undo and redo, handle pasted content more faithfully, and provide tools such as slash commands, link controls, an image library, variable and glossary pickers, blocks within lists, and keyboard-focused editing.

### Source excerpt

We rebuilt the DeveloperHub editor from the ground up. Here is what is new, and why it makes writing and maintaining your documentation noticeably better.

## Introducing Kempt

DevFeed: [Introducing Kempt](<https://devfeed.tech/articles/introducing-kempt-39037.md>)

Original publisher: [Read original article](<https://www.zacsweers.dev/introducing-kempt/>)

Author: Zac Sweers

Published: 2026-06-23T00:00:23Z

Content type: release

Language: en

Sources: [Zac Sweers](<https://devfeed.tech/sources/zac-sweers.md>)

Topics: [formatting](<https://devfeed.tech/topics/formatting.md>), [pre-commit](<https://devfeed.tech/topics/pre-commit.md>), [hooks](<https://devfeed.tech/topics/hooks.md>), [ci](<https://devfeed.tech/topics/ci.md>), [repo](<https://devfeed.tech/topics/repo.md>), [Java](<https://devfeed.tech/topics/java.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Rust](<https://devfeed.tech/topics/rust.md>)

Tags: [ci](<https://devfeed.tech/tags/ci.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [hooks](<https://devfeed.tech/tags/hooks.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [pre-commit](<https://devfeed.tech/tags/pre-commit.md>), [repo](<https://devfeed.tech/tags/repo.md>), [rust](<https://devfeed.tech/tags/rust.md>)

### AI overview

The article introduces Kempt, a small project designed to replace heavy Gradle-based formatting setups with a repo-local pipeline for formatting and commit hooks. It supports Kotlin, Java, and Rust, and can run locally, in pre-commit hooks, and in CI.

### Source excerpt

Formatting should be boring, in the best possible way.

## Monotonic Indentation

DevFeed: [Monotonic Indentation](<https://devfeed.tech/articles/monotonic-indentation-35605.md>)

Original publisher: [Read original article](<https://www.yegor256.com/2026/05/24/monotonic-indentation.html>)

Author: Yegor Bugayenko (yegor256@gmail.com)

Published: 2026-05-23T21:00:00Z

Content type: opinion

Language: en

Sources: [Yegor Bugayenko](<https://devfeed.tech/sources/yegor-bugayenko.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Programming language](<https://devfeed.tech/topics/programming-language.md>), [Python](<https://devfeed.tech/topics/python.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [code-formatting-style](<https://devfeed.tech/tags/code-formatting-style.md>), [code-indentation-rule](<https://devfeed.tech/tags/code-indentation-rule.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [indentation-in-java](<https://devfeed.tech/tags/indentation-in-java.md>), [monotonic-indentation](<https://devfeed.tech/tags/monotonic-indentation.md>), [off-side-rule](<https://devfeed.tech/tags/off-side-rule.md>), [programming](<https://devfeed.tech/tags/programming.md>), [programming-language](<https://devfeed.tech/tags/programming-language.md>), [python](<https://devfeed.tech/tags/python.md>), [style](<https://devfeed.tech/tags/style.md>)

### AI overview

The article proposes monotonic indentation as a source-code formatting rule: indentation may increase by exactly one unit between adjacent lines but may decrease by any number of units. It presents the rule as an optional check for existing style checkers or as a standalone tool, and compares it with Python's off-side rule.

### Source excerpt

Between two adjacent lines, indentation may grow by one unit only, but may shrink by any number of units -- a rule that resolves most code formatting disputes.

## Make regular expressions easier to read

DevFeed: [Make regular expressions easier to read](<https://devfeed.tech/articles/make-regular-expressions-easier-to-read-37309.md>)

Original publisher: [Read original article](<https://muffinman.io/blog/make-regular-expressions-easier-to-read/>)

Author: Stanko

Published: 2025-03-31T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stanko Tadić](<https://devfeed.tech/sources/stanko-tadic.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Maintainability](<https://devfeed.tech/topics/maintainability.md>)

Tags: [example](<https://devfeed.tech/tags/example.md>), [extra](<https://devfeed.tech/tags/extra.md>), [join](<https://devfeed.tech/tags/join.md>), [maintainability](<https://devfeed.tech/tags/maintainability.md>), [readability](<https://devfeed.tech/tags/readability.md>), [regular-expressions](<https://devfeed.tech/tags/regular-expressions.md>), [value](<https://devfeed.tech/tags/value.md>)

### AI overview

The article presents a formatting technique for making complex regular expressions easier to read: split the expression into multiple string components, join them, and construct the final regex. The approach adds code and requires escaping backslashes, but enables scanning and comments that can improve readability and maintainability.

### Source excerpt

This is a simple formatting trick I use to make regular expressions more readable. The secret? Break them into multiple lines. To achieve this, format the regex as an array of strings and then concatenate the array into a single regex string. Example # Compare this example, written in a single line: const FILTER_REGEXP = /(?<name>blur|brightness|contrast|grayscale|hue-rotate|invert|opacity|saturate|sepia)\((?<value>-?\d*(?:\.\d*)?)(?<unit>\w*?)\)/g; with the multi-line version: const SUPPORTED_FILTERS = [ 'blur', 'brightness', 'contrast', 'grayscale', 'hue-rotate', 'invert', 'opacity', 'saturate', 'sepia', ].join('|'); const FILTER_REGEXP = new RegExp( [ `(?<name>${SUPPORTED_FILTERS})`, // filter name `\\(`, `(?<value>\-?\\d*(?:\\.\\d*)?)`, // value `(?<unit>\\w*?)`, // unit if any `\\)`, ].join(''), 'g' ); The multi-line version has a bit more code, but it's easier to scan and read. It also allows us to write comments for each section, clarifying the purpose of each part of the regex. I've found that complex expressions are much easier to write this way. I believe it greatly reduces the cognitive load for both the writer and the reader. Caveats # You'll need to escape the backslashes in regex strings. While this is a minor inconvenience, the readability benefits easily outweigh it. Conclusion # It boils down to personal preference, but I believe the extra code is worth it, as it improves readability and maintainability. This is especially true when dealing with notoriously difficult-to-parse complex regular expressions.

## Features to consider when choosing a documentation editor

DevFeed: [Features to consider when choosing a documentation editor](<https://devfeed.tech/articles/7-must-have-features-in-a-documentation-editor-in-2025-30962.md>)

Original publisher: [Read original article](<https://developerhub.io/blog/what-to-look-for-in-a-documentation-editor/>)

Author: Zaid Daba'een

Published: 2024-10-13T19:01:46Z

Content type: article

Language: en

Sources: [DeveloperHub.io](<https://devfeed.tech/sources/developerhub-io.md>)

Topics: [Documentation](<https://devfeed.tech/topics/documentation.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Syntax Highlighting](<https://devfeed.tech/topics/syntax-highlighting.md>)

Tags: [2025](<https://devfeed.tech/tags/2025.md>), [blocks](<https://devfeed.tech/tags/blocks.md>), [collaboration](<https://devfeed.tech/tags/collaboration.md>), [customizable](<https://devfeed.tech/tags/customizable.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [editor](<https://devfeed.tech/tags/editor.md>), [features](<https://devfeed.tech/tags/features.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [images](<https://devfeed.tech/tags/images.md>), [search](<https://devfeed.tech/tags/search.md>), [syntax-highlighting](<https://devfeed.tech/tags/syntax-highlighting.md>), [technical](<https://devfeed.tech/tags/technical.md>), [version-control](<https://devfeed.tech/tags/version-control.md>)

### AI overview

This article explains how technical writers can evaluate documentation editors. It discusses formatting options, blocks and custom elements, multimedia embedding, collaboration tools, version control, and search functionality.

### Source excerpt

Selecting the right documentation editor is essential for technical writers. Look for features like advanced formatting, customizable blocks, version control, and powerful search functionality. These tools enhance collaboration and ensure your documentation is clear, accessible, and easy to manage.

## Critique of Enforced Automated Code Formatters

DevFeed: [Critique of Enforced Automated Code Formatters](<https://devfeed.tech/articles/acab-fire-the-code-style-cop-in-your-head-30457.md>)

Original publisher: [Read original article](<https://dev.to/autonomousapps/acab-fire-the-code-style-cop-in-your-head-m8b>)

Author: Tony Robalik

Published: 2024-09-29T18:47:32Z

Content type: opinion

Language: en

Sources: [DEV Community: Tony Robalik](<https://devfeed.tech/sources/dev-community-tony-robalik.md>)

Topics: [formatting](<https://devfeed.tech/topics/formatting.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [IntelliJ IDEA](<https://devfeed.tech/topics/intellij-idea.md>)

Tags: [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [intellij-idea](<https://devfeed.tech/tags/intellij-idea.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [software](<https://devfeed.tech/tags/software.md>)

### AI overview

An opinion piece arguing against enforced automated code formatters, especially in the author's Kotlin, Gradle, and IntelliJ IDEA workflow. It distinguishes formatting enforcement from linting and questions whether consistent whitespace alone improves readability, maintainability, flow, or error prevention.

### Source excerpt

Photo by Karsten Winegeart on Unsplash Let's get something out of the way right at the start: I hate enforced automated code style formatters. This post started because I had an axe to grind, and I made the ill-advised decision to haul my grindstone out into the public square. Multiple times. Over weeks. Disclaimer! I primarily write Kotlin code that I build with Gradle, in Intellij IDEA (in order of importance). Since many of my complaints are about specific implementation-level issues with code style formatting tools, if you don't also build Kotlin with Gradle, don't worry about it! I'm just an internet crank and you are relieved from the duty of telling me how wrong I am. Second disclaimer! Enforced code style is not the same thing as linting for usage issues. I like linters! Please tell me I forgot to close a stream, or am calling a Java API with ambiguous nullability. Ok, let's gooooo. Arguments in favor of enforcement of consistent code style Consistent code style is better than inconsistent code style Sure. But what do we mean by better? The general claims are: More readable More maintainable Aids with achieving flow Contains fewer errors I think we've already run into an issue, which is we need to clarify what "style" means. Are we just talking about where we break lines and how long those lines are? Or do we mean something deeper? If we are talking about line breaks, I think the argument is pretty weak. Sure, all else being equal, if two pieces of source code follow the same general style, I will have an easier time with pattern-matching and "understanding" them. But what if my pattern-matching misleads me? What if I gloss over the fact that two structurally-identical blocks contain a single semantic difference that entirely changes the behavior? Maybe that single difference is easier to spot if the whitespace is identical, or maybe it's easier to miss because my brain too-readily dismisses the second block as identical to the first. This is actually what c

## Presenting @trivago/prettier-plugin-sort-imports

DevFeed: [Presenting @trivago/prettier-plugin-sort-imports](<https://devfeed.tech/articles/presenting-trivago-prettier-plugin-sort-imports-28016.md>)

Original publisher: [Read original article](<https://tech.trivago.com/post/2021-12-17-aprettierpluginthatsortsyourimports/>)

Author: Ayush Sharma Software Engineer; Learner; Open Source Enthusiast Follow

Published: 2021-12-17T00:00:00Z

Content type: tutorial

Language: en

Sources: [Trivago](<https://devfeed.tech/sources/trivago.md>)

Topics: [Prettier](<https://devfeed.tech/topics/prettier.md>), [import](<https://devfeed.tech/topics/import.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [TypeScript](<https://devfeed.tech/topics/typescript.md>), [modules](<https://devfeed.tech/topics/modules.md>), [formatting](<https://devfeed.tech/topics/formatting.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [frontend](<https://devfeed.tech/tags/frontend.md>), [import](<https://devfeed.tech/tags/import.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [modules](<https://devfeed.tech/tags/modules.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [plugin](<https://devfeed.tech/tags/plugin.md>), [typescript](<https://devfeed.tech/tags/typescript.md>)

### AI overview

trivago released @trivago/prettier-plugin-sort-imports, a Prettier plugin that sorts TypeScript and JavaScript import declarations according to a configured order. The article explains its motivation, configuration, and handling of third-party and local modules.

### Source excerpt

I'm happy to share that trivago has released a Prettier plugin which sorts import declarations in TypeSCript and JavaScript modules for a given configured order. Throughout this article, I'll explain to you the motivation behind this Prettier plugin and how it works in detail.

## Learning Zig - Day 2

DevFeed: [Learning Zig - Day 2](<https://devfeed.tech/articles/learning-zig-day-2-38541.md>)

Original publisher: [Read original article](<https://msfjarvis.dev/posts/learning-zig--day-2/>)

Author: Harsh Shandilya

Published: 2021-05-15T06:30:00Z

Content type: tutorial

Language: en

Sources: [Posts on Harsh Shandilya](<https://devfeed.tech/sources/posts-on-harsh-shandilya.md>)

Topics: [Zig](<https://devfeed.tech/topics/zig.md>), [Code](<https://devfeed.tech/topics/code.md>), [syntax](<https://devfeed.tech/topics/syntax.md>), [test](<https://devfeed.tech/topics/test.md>), [formatting](<https://devfeed.tech/topics/formatting.md>)

Tags: [array](<https://devfeed.tech/tags/array.md>), [getting-started](<https://devfeed.tech/tags/getting-started.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [learn](<https://devfeed.tech/tags/learn.md>), [learning](<https://devfeed.tech/tags/learning.md>), [rust](<https://devfeed.tech/tags/rust.md>), [testing](<https://devfeed.tech/tags/testing.md>), [zig](<https://devfeed.tech/tags/zig.md>)

### AI overview

A second-day learning journal about Zig covers rebuilding a Rust library, using ziglearn.org, and early observations about Zig's defaults, arrays, testing, and defer feature. The author compares several behaviors with Rust and notes unresolved questions about formatting and diagnostics.

### Source excerpt

Onwards in our quest to learn Zig

## 8 Common Web Development Mistakes and How to Avoid Them

DevFeed: [8 Common Web Development Mistakes and How to Avoid Them](<https://devfeed.tech/articles/8-common-web-development-mistakes-and-how-to-avoid-them-35047.md>)

Original publisher: [Read original article](<https://markushatvan.com/blog/8-common-web-development-mistakes-and-how-to-avoid-them/>)

Published: 2020-10-19T00:00:00Z

Content type: tutorial

Language: en

Sources: [Markus Hatvan](<https://devfeed.tech/sources/markus-hatvan.md>)

Topics: [Web Development](<https://devfeed.tech/topics/web-development.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>), [Code quality](<https://devfeed.tech/topics/code-quality.md>), [ESLint](<https://devfeed.tech/topics/eslint.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Developer experience](<https://devfeed.tech/topics/developer-experience.md>)

Tags: [best-practices](<https://devfeed.tech/tags/best-practices.md>), [code-quality](<https://devfeed.tech/tags/code-quality.md>), [eslint](<https://devfeed.tech/tags/eslint.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [web-development](<https://devfeed.tech/tags/web-development.md>)

### AI overview

This tutorial describes eight common web development mistakes and recommends practices to avoid them. It emphasizes setting realistic project scope, establishing code quality tools early, and using ESLint to identify inconsistent or error-prone code before it requires major refactoring.

### Source excerpt

To save you valuable time on your web development projects in the future, make sure to avoid these eight common web development mistakes.

## Avoiding fake italic and bold text on Android

DevFeed: [Avoiding fake italic and bold text on Android](<https://devfeed.tech/articles/avoiding-fake-italic-and-bold-text-on-android-29017.md>)

Original publisher: [Read original article](<https://saket.me/android-fake-vs-true-bold-and-italic/>)

Author: Saket Narayan

Published: 2019-12-18T00:08:59Z

Content type: tutorial

Language: en

Sources: [Saket Narayan](<https://devfeed.tech/sources/saket-narayan.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Font](<https://devfeed.tech/topics/font.md>), [formatting](<https://devfeed.tech/topics/formatting.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [fonts](<https://devfeed.tech/tags/fonts.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [legibility](<https://devfeed.tech/tags/legibility.md>), [textview](<https://devfeed.tech/tags/textview.md>)

### AI overview

This Android typography tutorial explains that fake bold and italic styling is produced when the platform cannot find the requested font variant. It describes the resulting effects on visual differentiation and legibility, and recommends applying the complete font family so true variants can be selected.

### Source excerpt

Changing line heights in Android using LineHeightSpan has this ugly side-effect where the cursor ends up being very tall, extending till the full line height instead of just the text height. I've decided to go to extreme lengths to fix this over the next few days. For science. pic.twitter.com/2tWLvDq1rz -- Saket Narayan (@Saketme) November 24, [...] The post Avoiding fake italic and bold text on Android appeared first on Saket Narayan.

## JavaScript 'time ago' function

DevFeed: [JavaScript 'time ago' function](<https://devfeed.tech/articles/javascript-time-ago-function-37300.md>)

Original publisher: [Read original article](<https://muffinman.io/blog/javascript-time-ago-function/>)

Author: Stanko

Published: 2018-02-28T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stanko Tadić](<https://devfeed.tech/sources/stanko-tadic.md>)

Topics: [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Code](<https://devfeed.tech/topics/code.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [function](<https://devfeed.tech/topics/function.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [function](<https://devfeed.tech/tags/function.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [snippet](<https://devfeed.tech/tags/snippet.md>)

### AI overview

A reusable JavaScript time-ago function formats dates into relative or calendar-style strings, including seconds, minutes, today, yesterday, current-year dates, and older dates. The snippet is designed to remain customizable for project-specific needs.

### Source excerpt

Snippet for a rather popular requirement. Formatting a date in a nice way, using infamous "time ago" function. This is the basic version which I adapt to fit a specific project. To keep it easily customizable to your needs, I haven't packaged it up. Just pass a date to it, and function will return one of the seven possible formats: now - if no more than five seconds elapsed about a minute ago - in no more than ninety seconds elapsed 24 minutes ago - for anything in the last hour Today at 11:19 - for today Yesterday at 7:32 - for yesterday 15. February at 17:45 - for dates in the current year 23. October 2017. at 0:59 - for anything else Feel free to play with it and add more cases if you need them. Code # const MONTH_NAMES = [ 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December' ]; function getFormattedDate(date, prefomattedDate = false, hideYear = false) { const day = date.getDate(); const month = MONTH_NAMES[date.getMonth()]; const year = date.getFullYear(); const hours = date.getHours(); let minutes = date.getMinutes(); if (minutes < 10) { // Adding leading zero to minutes minutes = `0${ minutes }`; } if (prefomattedDate) { // Today at 10:20 // Yesterday at 10:20 return `${ prefomattedDate } at ${ hours }:${ minutes }`; } if (hideYear) { // 10. January at 10:20 return `${ day }. ${ month } at ${ hours }:${ minutes }`; } // 10. January 2017. at 10:20 return `${ day }. ${ month } ${ year }. at ${ hours }:${ minutes }`; } // --- Main function function timeAgo(dateParam) { if (!dateParam) { return null; } const date = typeof dateParam === 'object' ? dateParam : new Date(dateParam); const DAY_IN_MS = 86400000; // 24 * 60 * 60 * 1000 const today = new Date(); const yesterday = new Date(today - DAY_IN_MS); const seconds = Math.round((today - date) / 1000); const minutes = Math.round(seconds / 60); const isToday = today.toDateString() === date.toDateString(); const isYesterday = yesterday.toDateString()

## Nicer git log

DevFeed: [Nicer git log](<https://devfeed.tech/articles/nicer-git-log-37321.md>)

Original publisher: [Read original article](<https://muffinman.io/blog/nicer-git-log/>)

Author: Stanko

Published: 2017-04-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stanko Tadić](<https://devfeed.tech/sources/stanko-tadic.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [Scripting, bash](<https://devfeed.tech/topics/scripting-bash.md>)

Tags: [bash](<https://devfeed.tech/tags/bash.md>), [command](<https://devfeed.tech/tags/command.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [git](<https://devfeed.tech/tags/git.md>), [graph](<https://devfeed.tech/tags/graph.md>), [pretty](<https://devfeed.tech/tags/pretty.md>), [terminal](<https://devfeed.tech/tags/terminal.md>)

### AI overview

A short tutorial showing how to use git log's built-in --graph and --pretty=format options to produce a more readable terminal display, then save the command as a .bash_profile alias.

### Source excerpt

Just a short one. I want to share a simple command to display nicer git log in the terminal. git log has --pretty=format option built-in, we are just going to pass formatting to it. git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' And it looks like this: Then add it to your .bash_profile as an alias (I'm using glog) and that's it. alias glog="git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'"

## Maintainability and Expect Literals

DevFeed: [Maintainability and Expect Literals](<https://devfeed.tech/articles/maintainability-and-expect-literals-31920.md>)

Original publisher: [Read original article](<http://blog.jayfields.com/2016/06/maintainability-and-expect-literals.html>)

Author: Jay (noreply@blogger.com)

Published: 2016-06-16T11:21:00Z

Content type: opinion

Language: en

Sources: [Jay Fields](<https://devfeed.tech/sources/jay-fields.md>)

Topics: [Maintainability](<https://devfeed.tech/topics/maintainability.md>), [unit test](<https://devfeed.tech/topics/unit-test.md>), [test](<https://devfeed.tech/topics/test.md>), [Code](<https://devfeed.tech/topics/code.md>), [function](<https://devfeed.tech/topics/function.md>), [formatting](<https://devfeed.tech/topics/formatting.md>)

Tags: [advice](<https://devfeed.tech/tags/advice.md>), [alternatives](<https://devfeed.tech/tags/alternatives.md>), [code](<https://devfeed.tech/tags/code.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [function](<https://devfeed.tech/tags/function.md>), [literals](<https://devfeed.tech/tags/literals.md>), [maintainability](<https://devfeed.tech/tags/maintainability.md>), [readability](<https://devfeed.tech/tags/readability.md>), [test](<https://devfeed.tech/tags/test.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-test](<https://devfeed.tech/tags/unit-test.md>), [unit-testing](<https://devfeed.tech/tags/unit-testing.md>), [wewut](<https://devfeed.tech/tags/wewut.md>), [xunit](<https://devfeed.tech/tags/xunit.md>)

### AI overview

The author argues that literal expected values in unit tests improve readability and keep failures focused, while helper functions can broaden the scope of maintenance and couple tests. For changing or inconsistent strings, the article suggests duplication with bulk edits or testing variable-dependent behavior separately from formatting.

### Source excerpt

Recently, Stephen Schaub asked the following on the wewut group: Several of the unit test examples in the book verify the construction of both HTML and plain text strings. Jay recommends using literal strings in the assertions. However, this strikes me as not a particularly maintainable approach. If the requirements regarding the formatting of these strings changes (a very likely scenario), every single test that verifies one of these strings using a literal must be updated. Combined with the advice that each test should check only one thing, this leads to a large number of extremely brittle tests. Am I missing something here? I can appreciate the reasons Jay recommends using literals in the tests. However, it seems that we pay a high maintainability price in exchange for the improved readability. I responded to Stephen; however, I've seen similar questions asked a few times. Below are my extended thoughts regarding literals as expected values. In general, given the option of having many similar strings (or any literal) vs a helper function, I would always prefer the literal. When a test is failing I only care about that single failing test. If I have to look at the helper function I no longer have the luxury of staying focused on the single test; now I need to consider what the helper function is giving me and what it's giving all other callers. Suddenly the scope of my work has shifted from one test to all of the tests coupled by this helper function. If this helper function wasn't written by me, this expansion in scope wasn't even my decision, it was forced upon me by the helper function creator. In the best case the helper function could return a single, constant string. The scope expansion becomes even worse when the helper function contains code branches. As for alternatives, my solution would depend on the problem. If the strings were fairly consistent, I would likely simply duplicate everything knowing that any formatting changes can likely be addressed usin

## Writing more legible SQL

DevFeed: [Writing more legible SQL](<https://devfeed.tech/articles/writing-more-legible-sql-41186.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2016/01/08/Writing-more-legible-SQL/>)

Author: Map

Published: 2016-01-08T20:55:56Z

Content type: tutorial

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [SQL](<https://devfeed.tech/topics/sql.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [Code](<https://devfeed.tech/topics/code.md>), [standard](<https://devfeed.tech/topics/standard.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [sql](<https://devfeed.tech/tags/sql.md>), [standard](<https://devfeed.tech/tags/standard.md>)

### AI overview

The article recommends formatting SQL for readability and maintainability. Its suggestions include putting one column, table, or join per line; aligning projections and conditions; using explicit column names in grouping and ordering; commenting queries; adopting consistent keyword casing; and using CTEs to make complex queries easier to reason about.

### Source excerpt

A number of times in a crowd I've asked how many people enjoy writing SQL, and often there's a person or two. The follow up is how many people enjoy reading other people's SQL and that's unanimously 0. The reason for this is that so many people write bad SQL. It's not that it doesn't do the job, it's just that people don't tend to treat SQL the same as other languages and don't follow strong code formatting guidelines. So, of course here's some of my own recommendations on how to make SQL more readable. One thing per line Only put a single column/table/join per line. This is going to make for slightly more verbose SQL, but it will be easier to read and edit.. Here's a basic example: SELECT foo, bar FROM baz Align your projections and conditions You can somewhat see this in the above with foo and bar being on the same line. This is reasonably common for columns you're selecting, but it's not applied as often in AND or GROUP BY clauses. As you can see there is a difference though between: SELECT foo, bar FROM baz WHERE foo > 3 AND bar = 'craig.kerstiens@gmail.com' And a cleaner version: SELECT foo, bar FROM baz WHERE foo > 3 AND bar = 'craig.kerstiens@gmail.com' Use column names when grouping/ordering This is personally an awful habit of mine, but it is extremely convenient to just order by the column number. In the above query we could just ORDER BY 1. This is especially easy when column 1 may be something like SUM(foo). However, ensuring you explicitly ORDER BY SUM(foo) will help limit any misunderstanding of the data. Comments You comment your code all the time, yet so few seem to comment their queries. A simple -- allows you to inline a comment, perhaps where there's some oddities to what you're joining or just anywhere it may need clarification. You can of course go much further, but at least some basic level of commenting should be required. Casing As highlighted in these examples, having a standard for how you case your queries is especially handy. Sticking wit

## Markdown quick reference

DevFeed: [Markdown quick reference](<https://devfeed.tech/articles/markdown-quick-reference-35433.md>)

Original publisher: [Read original article](<https://darkcoding.net/software/markdown-quick-reference/>)

Author: Graham King

Published: 2006-05-09T22:18:18Z

Content type: tutorial

Language: en

Sources: [Graham King](<https://devfeed.tech/sources/graham-king.md>)

Topics: [Markdown](<https://devfeed.tech/topics/markdown.md>), [formatting](<https://devfeed.tech/topics/formatting.md>), [syntax](<https://devfeed.tech/topics/syntax.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [conversion](<https://devfeed.tech/tags/conversion.md>), [formatting](<https://devfeed.tech/tags/formatting.md>), [guide](<https://devfeed.tech/tags/guide.md>), [markdown](<https://devfeed.tech/tags/markdown.md>), [software](<https://devfeed.tech/tags/software.md>), [syntax](<https://devfeed.tech/tags/syntax.md>)

### AI overview

A quick reference guide to Markdown syntax, explaining how plain text is converted to structurally valid XHTML or HTML and showing examples of headers, links, blockquotes, code, lists, horizontal lines, emphasis, and escaping.

### Source excerpt

A markdown masterclass, where plain text shines.