[ $davids.sh ] — david shekunts blog

**Comments + Markdown = 🖤

# [ $davids.sh ] · message #167

**Comments + Markdown = 🖤

**One of the most important tasks in coding is to make it understandable for other developers and your future self. And for this, there are 3 main tricks:

  1. Write simpler constructs. If / else, instead of ternary operators, for loop instead of filter + map + reduce (namely, when you have to use all 3 in combination), pre-calculate predicates, assign them to a union type, and make a switch, instead of multiple nested if / else.

  2. Extract code into functions. This is, by the way, one of the bonuses of the declarative style, when thanks to the function name, input and output typing, you can understand "what" is happening, rather than reading the code that describes "how" it happens.

  3. Add comments to the code.

**And about the last point, it's rare to find useful information, so I've developed a few cool principles for myself:

  1. Comment Driven Development – I very often first write comments in a function about what it should do, and only then write the code. This allows me to see and solve logical collisions in advance.

  2. Use Markdown.

**Example without Markdown:

// First comment const foo = await bar()

if (foo) { // Second comment await helloWorld() }

// Third comment const ping = await ping()

Now, can you say: are First comment and Third comment related or not? That is, is it the next step in the code or part of the previous one?

The answer can only be guessed.

But if you use Markdown:

// # First comment const foo = await bar()

if (foo) { // ## Second comment await helloWorld() }

// # Third comment const ping = await ping()

As you can see, I denote through Markdown "chapters" of the code, as if it were regular text. Thanks to this, you can clearly understand that Third comment is a new "chapter" (the next step).

With this simple movement of the hand, your comments acquire much more context and clarity for other developers.

What tricks do you use to write comments?

  • @ Ivan ITK 🚫 · # 348

    Tell me more about why markdown headings are needed in comments? Generally, I use regular jsdoc with markdown in the description or examples sections. However, I’ve never written headings, for example, JetBrains can render jsdoc from text into markdown preview, and it might not be very readable if headings are used. But, it’s interesting, I’ll experiment with it)

  • @ Ivan ITK 🚫 · # 349

    And I'm also curious, which approach do you prefer - API-design first vs code-first?

  • @ [ $davids.sh ] · # 355

    I'm not shy about writing procedural code, and some of my functions can reach 1000 lines of code.

    The most vivid example: parsing data from IoT devices. The thing is, some data properties can heavily influence others, and if we were to create separate functions for each processing step (passing data immutably between them), we'd eventually end up in a situation where one deep branch of logic starts depending on another, forcing us to refactor extensively.

    That's why I prefer to keep most of the logic in one main parsing function. Only when I'm sure that a branch is independent or its depth is no more than 1-2 levels do I extract it into separate functions.

    In such procedural code, situations arise where 50-100 lines of code represent a "chapter" with "subchapters," and I want to mark these somehow.

    For this, I write comments before each chapter, like "// Extracting sale data," "// Updating state," "// Deduplication," and so on.

    But if I just write comments, at some point the question arises: is this comment related to the previous one or not?

    When I start adding Markdown rules to them (mainly headings, lists, and sometimes bold, italic, etc.), I can much more clearly see which piece of code belongs to which chapter, and navigating through the function becomes much easier.

    And yes, I use JSDoc when I want to describe the function itself, but that's more about "what happens here" rather than "how it happens."

  • @ [ $davids.sh ] · # 357

    When I design a system or a major feature, I go API-design first, but for everyday tasks I might do code-first.

    I'm a fan of Task-based UI and CQRS (from the perspective of separating Read and Write models), so my APIs consist of lots of small requests for modifying or retrieving data, with very few reusable interfaces between them (each is practically written specifically for a given endpoint).

    So when designing, I usually take my dataset from various sources (like a DB), identify the tasks the client (UI or service) wants to accomplish, and assemble a set of APIs, describing them in some notation (whether OpenAPI, protobuf, or TypeScript if it's a monolith).

    By the way, interesting question (I’ll make a post about it)), what’s your take on this?

  • @ Ivan ITK 🚫 · # 362

    You need to elaborate a lot here. I've practiced and developed both approaches. There are nuances everywhere.
    Overall, I currently follow a strategy similar to yours—it largely depends on the input resources for decision-making.