DEV Community: Patrick Ahmetovic

Let the computer do the work.

Patrick Ahmetovic — Mon, 08 Mar 2021 20:58:57 +0000

I don't particularly appreciate spending a fair amount of time reading through documentation about style guides, team conventions, guidelines, and more. I wouldn't say I like having to think about every reference in those documentation pages to make sure that I don't write code that is violating any of these.

That is why I usually try to let the computer do the work. Here are some notes about the tools I like to use:

ESLint

ESLint is a linting tool that can cover many aspects of your source code. For example, I could enable the eqeqeq rule and automatically check that I'm using === instead of == in my conditions.

// ESLint will suggest using === instead of ==
if (iWrite == thisCondition) {
  console.log('ESLint will complain.')
}

Since the configuration file is extensible, different settings can be shared across the team, organization, or the world. This way, I can specify rules by providing a config and, whenever a rule is broken, give feedback without me needing to check it manually.

Prettier

Promoted as an opinionated code formatter, Prettier rectifies the need to discuss things like tabs and spaces and other formatting concerns. Instead, the code is formatted through rules defined in a config file.

It can format the code on save, check if the code is not formatted correctly, and automatically fix most of the errors.

I like to use ESLint for style guide purposes (like the eqeqeq rule mentioned above) while Prettier takes care of my code's formatting.

stylelint

Stylelint is a linter similar to ESLint, but instead of checking JavaScript code, stylelint will validate your stylesheets instead.

Much of the same benefits of ESLint apply. With stylelint, I can specify and enforce code styles and practices throughout the CSS code I write.

TypeScript

As a superset of JavaScript, TypeScript enables developers to add types to JS code. The TypeScript compiler can provide quick feedback should the code contain errors that can be determined statically.

const add = (a: number, b: number) => {
  return a + b
}

add(1, 'a')

TypeScript would catch the invalid type string of the second argument we pass to the add function. These checks can catch a lot of unexpected errors even without ever having to run the code.

Testing

Writing self-testing code is a topic in itself. However, I want to give notes on some of the tools I've liked to use so far:

Jest

Jest is a testing framework that offers an extensive API for writing your tests. It comes with a nifty --watch mode, as well as a plethora of different assertion possibilities and excellent mocking capabilities. Paired with additional features such as coverage reports, custom matcher support, and plugin support, I've primarily used Jest for testing my code.

Cypress

Cypress is a great way to write E2E tests that can verify use cases involving multiple system components without mocking parts.

Instead of manually clicking around on a webpage, Cypress will go through the commands with an automated runner. While doing that, assertions can automatically check if everything is as expected.

Testing Libary suite

I am a fan of the Testing Library suite, specifically the Vue Testing Library and React Testing Library. These test utilities allow me to write my tests in a more readable way while implicitly checking other aspects of my code, such as accessibility.

import { render, screen } from '@testing-library/vue'
import userEvent from '@testing-library/user-event'
import Counter from './my-path/Counter.vue'

test(`updates the displayed text with correct counter value`, () => {
  render(Counter)

  screen.getByText('Counter is: 0')
  userEvent.click(screen.getByRole('button', {name: /increment/i}))

  screen.findByText('Counter is: 1')
})

In the future, I want to explore the Cypress Testing Library as well to use a similar API as the other Testing Libraries for E2E tests.

Husky for git hooks

husky is a great package that lets me add git hooks with ease. These hooks provide points at which I can run custom code for various purposes.

{
  "husky": {
    "hooks": {
      "pre-commit": "eslint . --ext .js,.ts"
    }
  }
}

Most of the time, I've used husky to add a pre-commit hook that runs a custom validate script (using many of the tools mentioned in this post). On failure, the developer cannot commit the code and has first to fix the issues. That enables a rapid feedback loop and ensures that the necessary checks have been made before making a commit.

lint-staged

lint-staged is a package that runs specified commands only against staged files. That avoids checking your whole project by narrowing it down to the files that will get committed next.

For me, husky and lint-staged go hand in hand together, meaning I usually configure husky to call my lint-staged script.

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.js": "npm run validate"
  }
}

Further notes

One of the projects I didn't use yet but would like to is commitlint. commitlint can transfer rules and concepts from conventional commits to a config file. It then lints git commit messages and tries to find violations against those rules.

Non-Prop Attributes in Vue

Patrick Ahmetovic — Tue, 23 Feb 2021 10:50:12 +0000

During the implementation of a custom component, I explored the documentation to learn about a behavior that previously seemed a bit magical to me: Non-Prop Attributes.

Props in Vue

props are one of the ways you can implement component communication in Vue. It is pretty similar to React and provides an API to express the properties such as type, required, and default.

As an example, let's look at an input component that receives a prop named value.

// BaseInput.vue
<template>
  <div>
    <input v-bind="$attrs" :value="value">
  </div>
</template>

<script>
export default {
  name: 'BaseInput',
  props: {
    value: {
      type: String,
      required: true,
    },
  },
}
</script>

And here's a possible usage:

// MyComponent.vue
<template>
  <BaseInput :value="foo" />
</template>

Non-Prop Attributes

But what if you do this?

// MyComponent.vue
<template>
  <BaseInput :value="foo" :readonly="isReadOnly" />
</template>

Here readonly is not defined in the props definition of BaseInput:

// BaseInput.vue
<script>
export default {
  // ...
  props: {
    value: {
      type: String,
      required: true,
    },
    // No definition for readonly
  },
  // ...
}
</script>

So what happens with it?

In such cases, Vue adds these attributes to the $attrs object accessible as an instance property. In the example above, readonly gets added to the object as $attrs.readonly:

{
  "readonly": true
}

Attribute Inheritance

Attribute inheritance (and disabling it) can leverage the usage of Non-Prop attributes. By default, attributes are added to the root element of your template. For example:

// BaseInput.vue
<template>
  <div>
    <input type="text" />
  </div>
</template>

// MyComponent.vue
<BaseInput data-testid="my-component-id" />

Will result in:

<div data-testid="my-component-id">
  <input type="text">
</div>

Using inheritAttrs: false, we can opt-out of this default behavior to tell Vue that we are explicitly going to bind the attributes where we need to. In the example above, we may want to set the input element's attributes rather than the outer div. To do that, we add v-bind="$attrs" to the input element.

// BaseInput.vue
<template>
  <div>
    <input type="text" v-bind="$attrs" />
  </div>
</template>

<script>
export default {
  inheritAttrs: false,
  // ...
}
</script>

Now, <BaseInput data-testid="my-component-id" /> will result in:

<div>
  <input type="text" data-testid="my-component-id">
</div>

That is especially useful when all the possible attribute keys are either unknown beforehand or tedious to manually define as a prop. For instance, an input element can have a multitude of different attributes such as value, disabled, type, readonly, and more. Another example would be to add data-testid (or other data attributes) for testing purposes or integration with 3rd party libraries.

Note: In Vue 2, the class and style attributes are not added to $attrs. That means that despite using inheritAttrs: false, these two attributes are added to the root element no matter what. This behavior changed in Vue 3 by adding them to $attrs as well.

Tailwind. My experience using it for a month now.

Patrick Ahmetovic — Sat, 10 Oct 2020 16:15:36 +0000

Let's be honest. Writing CSS can sometimes be a b*tch. As projects grow larger, the CSS styles can become quite hard to maintain - from naming things, trying to align content perfectly and figuring out which selector overrules your new styles.

As a result, people have come up with many ways to make it easier for us. Some like to use CSS-in-JS. Others are vigilant about using BEM naming to make sure their styles are named descriptively. Frameworks such as Bootstrap & Tailwind are helping by providing a pre-defined API you can use to make your designs come to life.

I was recently excited to hear that I got the chance to use Tailwind in one of our new projects. I have been meaning to learn more about it as I have heard good feedback within the community and online channels.

This post is a short summary of all the things I got to learn about Tailwind during the first month of using it and what my experiences were like.

What is Tailwind?

Tailwind promotes itself as a "utility-first CSS framework for rapidly building custom designs." The philosophy of Tailwind is to provide an API (utility classes) which you can combine to go from design to implementation. Using these classes in your HTML markup has another effect: all your styles are visible from within the markup itself. What do I mean by that? Let's look at an example:

The example shows an image with a rounded border and box shadow applied. The image is contained in a div that defines padding around it.

As you can see, not a single (custom) CSS rule was needed. Everything was achieved by using the utility classes Tailwind provides. We are able to get a sense of how the element will be styled just by looking at the HTML directly.

Tailwind offers many features that make this possible: built-in functionalities for responsive design, pseudo-class variants and other things. Please make sure to check out the docs to get a sense of all the cool things Tailwind can do.

Alright enough about Tailwind. How was my experience?

Pros:

It's customizable.

Tailwind has been built with customizability in mind. As of now, I was able to easily change spacing values, font families or colors with ease. The great thing about this is that Tailwind does not restrict you in any way. Although it provides (in my opinion) very sensible default values, you are free to change them as you please.

It establishes a rule set for both developers & designers.

With the power of customizability, Tailwind (or more so the Tailwind config) is great at being the source of truth for your designs. After collaborating with designers, it is easy to transfer the properties & values agreed upon (e.g. spacing) to Tailwind. This helps tremendously when implementign designs as all the values (ideally) are in the pool of utility classes. If, for whatever reason, one of those values is modified, all changes are immediately visible in all parts of your application. As an example, let's suppose you change the font size value for xl from 1.25rem (the default) to 1.35rem. Now every element you have applied the text-xl utility class will automatically use your new value.

No naming. No problems.

Although I initially thought that this aspect will only play a minor role for my development workflow, I have got to love not having to come up with well-named CSS classes. While previously I have enjoyed using BEM naming, I still had to regularly debate with myself on how I should name certain elements. Tailwind removes that part entirely, making you focus more on what really matters: the styles to use.

Specificity.

As projects grow bigger, maintaining CSS styles tend to also become harder. During the first month, I could also observe that another advantage to using Tailwind is that it requires no effort to overwrite (or add) new styles. In a perfect world, developers wouldn't have to address overly specific CSS selectors which overrule newly applied styles. Unfortunately, I don't live in this perfect world. In the past I have seen selectors constantly clashing with my styles, thus leaving me to add other overly specific styles. While this is not ideal, I am happy to see that Tailwind (so far) removed this as each element is only composed of the utility classes they need.

Cons:

One off styling.

One of the biggest advantages of Tailwind is that you can craft a well defined configuration upon which your utilties are generated. However, this is also part of one of my biggest pain points - one off styling. Sometimes the design requires to go out of bounds with the options that are laid out to you. Sure you can discuss to add them in the config but sometimes that is also not the best option, as this style might only really be needed in that specific case.

In Adam Wathan's great talk on Tailwind best practices, he mentions that using inline styles can be useful to go around these obstacles. In most cases this tip was already enough for me and I was able to happily move on. In other cases, it still didn't feel quite right (keeping in mind that this is subjective). As an example, inline styles do not support media queries which you might need for one off cases.

Your markup may get polluted.

Moving all your CSS rules from a stylesheet to the HTML markup naturally makes your class="" attributes grow quite large. Especially when the element needs a lot of those to be responsive and look good on all devices.

I am not bothered much by it. However, I can understand if other developers may find it ugly or too "noisy".

Final thoughts

I have been using Tailwind for a month now. So far I have enjoyed the process and I am excited to see how using this framework will scale as more and more of my projects will use it. I would recommend everyone to spend little time playing around with Tailwind and see how well it integrates with your projects.

If you have used Tailwind, have any questions or just want to say hi, please feel free to comment below. You can also reach out to me on Twitter.

Why I like srcset and why you'll like it too - a quick guide to resolution switching

Patrick Ahmetovic — Fri, 09 Oct 2020 13:32:40 +0000

It is hard to keep focus on all the different problems we are facing to deliver the best possible experience to our users. One of those is the question of "How can I use sharp images (e.g. for high-DPI devices) while not draining bandwidth for users who might not need it?"

This post is a short (but hopefully sweet) introduction to srcset with a focus on resolution switching- a really neat way to solve this problem.

What is srcset?

srcset is oftentimes used as an attribute for an HTML <img> element. Its purpose is to provide a list of image sources (i.e. URLs) from which the browser can choose from based on additional information you are providing. In this post, we are going to focus on specifying the resolutions. However, please note that srcset also supports other use cases - feel free to check them out here. Here's a short example on how you can define a list of images along with their resolutions:

<img
    src="image_1x.jpg"
    srcset="
        image_1x.jpg 1x,
        image_2x.jpg 2x"
    alt="A beautiful alt description of some image"
/>

In simplified terms, we are basically saying: "Look browser, I have a srcset defined - image_1x.jpg is 1x resolution (basically the base), image_2x.jpg is 2x the resolution" and so on. The browser can then use this information to decide which image to render.

Note: in the above example, you could also just use image_1x.jpg, instead of image_1x.jpg 1x, because 1x is implied. However, I personally like to specify it either way to make it more explicit.

Alright. But how does that help me and the user?

The benefit of using this approach is that the browser will be able to determine what the user will need. Suppose the user is looking at the page using a high-DPI screen (think of Retina devices), the browser will be able to recognize it and say "Whoops, we got a nice screen with good resolution.. the 1x resolution probably won't make the cut so I'll better request and use the image defined as 2x."

The cool part is that this way, you automatically save your users bandwidth when the higher resolution image is not needed as the browser will not make a request to get it.

Final thoughts

srcset is a very nice tool we can use to optimize our web pages even further. While I have only focused on specifying the resolution, please take a look at the other use cases you might find srcset helpful for.

Unfortunately, there's one thing I haven't mentioned yet and that is that srcset is not supported on IE11. If your project needs to support IE11 you will have to fall back on polyfills or other ways to achieve comparable results.

I hope you enjoyed this short post. Feel free to comment if you want to leave feedback or just want to say hello. You can also reach out to me at Twitter.

A Sticky Situation (position sticky in CSS)

Patrick Ahmetovic — Tue, 06 Oct 2020 10:37:24 +0000

Many months ago, I was finding myself implementing a sticky navigation bar using vanilla JS. Not because I didn't know about position: sticky; but because I needed to support IE11 (😢). So while this initially kept me from checking it out more closely, it made me even happier once I was finally able to use it later on.

This post is a short primer on what the sticky value is and where you might find it useful when implementing designs and layouts.

What is sticky?

sticky is one of the 5 values the position property can use as a keyword. Taking a look at the MDN documentation, we can learn that:

"The element is positioned according to the normal flow of the document, and then offset relative to its nearest scrolling ancestor and containing block (nearest block-level ancestor), including table-related elements, based on the values of top, right, bottom, and left. The offset does not affect the position of any other elements."

Let's simplify this statement a bit.

When using the keyword sticky, you have to specify at least one of the 4 following properties: top, right, bottom or left. In simplified terms, these values then determine the "offset" of the sticky behavior, meaning when the stickiness should start.

Let's take a look at a common use case to see how we would use the top property: A navigation bar that gets sticky when the user scrolls further down the page:

As you can see, the navigation bar sticks at the top of the page with (in this case) a zero pixel offset, essentially meaning right at the top of the screen. Feel free to go to the CodePen and play around with the top value. This way, you'll see that the navigation bar will start to stick sooner or later, depending on which value you've entered.

When you compare sticky to fixed, you can clearly see some similarities. When I was beginning to learn about the sticky value, I initially thought of it as "a delayed position fixed". While in some sense that's still how I think about it, an important aspect is that sticky is confined within the nearest scrollable ancestor.

Why would you care? Because that means, sticky stops being sticky when it reaches the end of the ancestor. This is a minor detail that initially didn't fit my "delayed fixed position" mindset. And because of that, I tried to come up with a quick visualization on what exactly I mean:

The sticky element stops right at the bottom of the container it is defined in. This is a really neat way to produce layout & designs that require an element to be sticky while scrolling through the page. I implemented a short prototype to show you a potential use case:

Final considerations

sticky made it much more convenient for developers to define elements that need to stick at certain regions of the page. While previously you had to rely on JavaScript for that, you can now simply use the built-in CSS properties to accomplish the same effect with much less overhead and implementation effort.

However, checking caniuse.com will show you that while the browser support overall is really good, you still have to think about IE11 if you still need to support it.

I hope this little post was able to help some to hear/learn about position sticky. If you have any feedback, tips or just generally want to say hi, please feel free to leave a comment. Alternatively, you can hit me up on Twitter as well.

Would I go to university again?

Patrick Ahmetovic — Mon, 24 Aug 2020 21:13:44 +0000

Note: This post will be about my experience studying computer science in Vienna. This means that I will probably leave out problems/thoughts/worries out of the room that people in other geographies may have - partially because I am just not aware of those and partially because they didn't apply to my studies. I still hope that you will enjoy the read.

Go to school, continue studies at university and you will get a good job. It's a simple 3-step process society has come up with to live a "successful" life - at least that's how I've picked it up living and growing up in Austria.

Now that I've finished my bachelor studies, I want to take some time to reflect on the things I have enjoyed or disliked while studying computer science.

The pros

Studying at a university comes with a lot of advantages. In this section I want to show some of the main reasons why I would consider doing it again.

Everything is planned out

Bachelor studies have the nice property that they follow a certain curriculum. You start with programming classes in the first semester, progress to more advanced algorithms in the second semester and find yourself writing distributed system applications in the fourth. All while simultaneously gathering knowledge in other fields like Operating Systems, Networking, Human-Computer Interaction and more.

This cuts out all the time you would need to research online to either build a plan yourself or find one that suits your needs.

Overcoming challenges

University is all about challenges. Exams, presentations, assignments, group projects - everything is a challenge in itself for which you must work hard to overcome those.

But I am forever grateful for these experiences - the night where I didn't know why my implementation of Dijkstra's Algorithm suggested going right instead of left, the hours I desperately tried to find how the solution to a math equation was "easily obtained" as suggested by the textbook or the worries I had when I saw the assignment title "Develop a ray-tracer" despite having no clue how it works (let alone how it should be implemented).

When looking at the field of programming, these experiences taught me a valuable lesson: Nobody knows everything in programming. Instead focus on the core concepts, familiarize yourself with the problem at hand, use the resources given to you (shout-out to Stack Overflow) and just try. More often than not, you will see that trying worked out and you've gained new skills and experiences along the way.

In doing that repeatedly, I have built the confidence to say that I can pick up any languages/frameworks/concepts as long as I just try and experiment.

Meeting new people

Universities are usually a confined space in which you wander around from one lecture hall to another. This naturally forces you to meet new people along the way and, eventually, build new relationships with some of them.

And since everyone is studying the same thing (my university had a separate faculty for computer science), the chances are higher to have common interests with the people around you.

I have met quite a lot of boys and girls during my time at university. With some of them I disconnected along the way, with others I have build strong relationships that reach far beyond the confinements of university and the related topics.

Building a network

Similar to the point above, you also interact with professors, tutors and other members of the university. And in some instances, promising opportunities arise from the conversations you have with them.

I have friends who have landed their first internships through recommendations of their professors. Others got a lead which they converted into stable part-time positions besides studies.

For example, I was fortunate enough to get a free ticket for the WeAreDeveloper congress from our faculty. There I have landed my first internship after collecting some courage to go to a booth and straight up ask for opportunities.

Cons

Unfortunately, not everything was a great experience. This section will unveil some which I consider to be the main pain points while studying at a university.

It is stressful

This statement is subjective. However, I am confident in saying that, for most students, computer science is not a piece of cake.

Each semester you get bombarded with gazillion facts, concepts, terms and other things related to your courses. When finals week arrives, your caffeine intake will probably increase by 400% in order to cram in the last details while you sit at your desk late in the night.

If you didn't want to fall behind, you had to work hard. For some the pace was just too quick so they eventually dropped out or put their studies on hold. But with enough ambition, it was possible to win the battle.

Not everything is up to date

As I've mentioned earlier, in university studies you follow a certain curriculum. While this is one of the main advantages it can also be seen as one of the greatest disadvantages - simply because some course materials are not up to date.

One day I was watching a talk given by Sven Peters. In this talk, he briefly
mentions how the waterfall model was oftentimes not suitable as a software development process and that we evolved to other (agile) methodologies. Well, guess what? I learned about the waterfall model one week prior to watching the talk in my Software Engineering class. On the contrary, my exposure to Scrum, Kanban and other methodologies at university was in the form of
one slide in a ~70 slides presentation.

I don't want to put that much weight on this example alone. In numerous instances my classes have failed to even look around to see what the current status quo is - which brings me to my next point.

You could teach yourself instead

Most of the time I studied for an exam or worked on an assignment I didn't look at the material that was provided by the professors. Instead, I looked at what topic I need to learn and tried to find videos and resources online - because in most cases they were far superior.

So why would you need the resources the professors have created? For me, the answer is that you don't really need them. I merely used them as reference for which topic we were currently at. I believe everyone can find the resources they need as long as they know what they want to learn.

I never had the impression that I had access to resources that people outside of university wouldn't have access to. You could buy the recommended books (or try to find it in a library), substitute the presentation slides with online articles and watch videos instead of lectures.

Classes don't prepare you for the real world

It may be my subjective perspective. But I believe that university alone fails to prepare you for the real world in software engineering.

I was fortunate enough to find a job as a frontend developer shortly after finishing my second semester. This way, I was able to develop skills that I would have never picked up to this extend during my studies. Here's an example tweet, touching on my point:

Given that we spend more time reading code than writing new one, I think it‘s a missed opportunity to not teach refactoring at university. My experience is that everything revolved around finishing new projects, never to improve an existing code
Patrick Ahmetovic (@patriscus)

At university, I never had to work on a bigger project, I never (really) had to read code written by others, I never had to resolve merge conflicts and I never even had to create a pull-request when we worked on a project as a team. I could go on but I'm trying to keep myself short.

I would just keep in mind that despite all the things you learn, the real world may present itself to be vastly different.

Final thoughts

While I had some unpleasant experiences I would consider my time at university as time well spent. However, I strongly believe that you do not need to get a degree in order to be a developer. At this day and age I would rather see university as an opportunity to meet like-minded people, build the discipline to work on tough topics and develop confidence along the way. You may choose to take those opportunities there, or you might choose to use meetups, platforms (like dev.to) and online classes (like freecodecamp.com) instead - in the end I am certain that you can succeed either way.

My experience writing a linter for Go

Patrick Ahmetovic — Sun, 09 Aug 2020 07:35:32 +0000

Linting your source code is oftentimes an integral part in software development processes. Whether it is to check if you misspelled words, violate against a certain code style or recklessly used tabs over spaces (don't worry, I won't judge), linters offer a great way to automate mundane tasks to free up time and energy for other things.

As the time had arrived for me to work on my bachelor thesis, I decided on implementing a linter for source code written in Go - primarily because I wanted to learn a new language and always wondered if I could write a linting application myself.

In this post I want to explain some of the concepts I have picked up while working on the project.

Linting using an Abstract Syntax Tree (AST)

Abstract Syntax Trees decompose your source code and represent it in a tree form. This way you can traverse the resulting tree, enabling you to collect information you are interested in.

Let's look at a really small example of what I mean by "tree form":

In Go, the standard package provides us with go/ast which already implements a lot of the functions you would typically need for building and traversing a tree.

In the scenario above, you would be able to inspect the components by looking at the .X (a) and .Y (b) components of .BinaryExpr (==).

For one of my use cases, I needed to check how many conditional operands a specific condition has. I then used the information to suggest decomposing the condition to smaller pieces if the count exceeds a limit.

The following code shows how a conditional statement gets evaluated to eventually obtain the total count of operands:

func (validator DecomposeConditionsValidator) evaluateConditionalExpression(stmt ast.Expr) int {
    switch expression := stmt.(type) {
    case *ast.BinaryExpr:
        return 1 + validator.evaluateConditionalExpression(expression.X) + validator.evaluateConditionalExpression(expression.Y)
    case *ast.ParenExpr:
        return validator.evaluateConditionalExpression(expression.X)
    default:
        return 0
    }
}

All the tree nodes are traversed in a recursive manner, thus providing us with the sum of operands when the recursive invocation stops.

Traversing the file system

Linting applications usually validate each file recursively, starting from a root directory. For each file, a AST is constructed which is then used as the input for the rules/validators setup by the author.

Usually you can use packages for your programming language that abstract the file system by providing methods to interact with it. I was surprised to see how neatly Go is supporting recursive traversal with path/filepath.

Here's a simplified view on how I used recursive file traversal:

err = filepath.Walk(linter.BaseDir, func(path string, info os.FileInfo, err error) error {
  // construct AST tree
  // initialize data structure to store results

  // for each rule
  //    check the AST tree
  //    append to the results

  // add results to a linting report structure 
}

// return linting report

Defining the rules (validators)

Now we have established how a linter traverses the file system and how source code is represented by an abstract syntax tree. Another crucial part of the system is the implementation of validators (or whatever you want to call them).

As an example, let's say you wanted to check the length of each variable name in order to suggest more expressive names when the length is only 1 (let's discard valid reasons you might use such short names - e.g. Point.X or Point.Y coordinates). You would then express this rule as functions/methods/classes (you choose), usually defined in separate files.
As an example, you can check how ESLint organizes their rules.

For the use case above, you could for example represent "fail when the variable name length is below a limit" as follows:

for _, elem := range statement.Lhs {
    switch identifier := elem.(type) {
        case *ast.Ident:
            if len(identifier.Name) < validator.Rule.Limit {
                result = stats.Failed
                identifierNames = append(identifierNames, identifier.Name)
            }
    }
}

Displaying the results

In order to decouple the presentation of the linting results from the creation, I defined a common report structure to store the output generated by the program. Here is a sample structure I have used for my linter:

type Report struct {
    Id           primitive.ObjectID `bson:"_id"`
    Timestamp    time.Time          `bson:"timestamp"`
    FileCount    int                `bson:"fileCount"`
    ErrorCount   int                `bson:"errorCount"`
    WarningCount int                `bson:"warningCount"`
    PassedCount  int                `bson:"passedCount"`
    Files        FileResultList     `bson:"files"`
}

Apart from the file results themselves, some metadata is stored for later processing. While the structure above may not be the most extensible one, it was sufficient enough for me to implement the requirements of the project.

For later display, I stored the results in MongoDB and retrieved them by using a REST API that is being called by a React frontend application.

Conclusion

It is interesting to see how many components need to interact
in order to provide valuable feedback for developers. First we traverse through the file system while constructing an abstract syntax tree for each file. Then we can lint the source code with validators to eventually display the results to the users.

However, given the short time span, I wasn't able to fully implement all of the capabilities a good linter usually provides. Some of them include:

Annotations to ignore lines or blocks of source code
Automatically fix warnings/errors found
Extensive configuration options
IDE integrations

While I have laid out some of the core components of my linter, I still hope to eventually return and learn more about the inner-workings of the mechanisms outlined above.