Moving Beyond Angular's Style Guide - Part 2: Small functions
Tags: angular, typescript, javascript, architecture
Published: 2020-04-02 15:01:04

---
title: Moving Beyond Angular's Style Guide - Part 2: Small functions
published: true
description: Learn why the "Small functions" rule could have a greater impact on your application than you think.
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/m6ywvtt60op6wj5ajcjc.jpg
tags: angular, typescript, javascript, architecture
series: Moving Beyond Angular's Style Guide
---

_In this series we look at some of the rules in [Angular's Style Guide](https://angular.io/guide/styleguide) that might need clarification or alteration as we grow our applications and our understanding 🧠 of the framework._

---

## 📐 The Rule in Question: [Small functions](https://angular.io/guide/styleguide#small-functions)

The Angular Style Guide defines this rule as follows:

> Do define small functions

> Consider limiting to no more than 75 lines.

---

## 💡 Positive Observations: Universally Useful

This rule is a rule to live by in software development!

Sometimes we will end up with large functions/methods/procedures, because the world isn't perfect 😭, but no one will ever _recommend_ we create **large** functions.

Small functions tend to abide by the [Single Responsibility Principle](https://en.wikipedia.org/wiki/Single-responsibility_principle) and can help with the [Interface Segregation Principle](https://en.wikipedia.org/wiki/Interface_segregation_principle).

If we don't do much in our functions, we decrease the number of dependencies we rely on, and make it easier to separate each function from the others. Small, easily composable pieces often result in a flexible architecture 💪🏿.

As with [The Rule of One](https://dev.to/seangwright/moving-beyond-angular-s-style-guide-part-1-rule-of-one-4bmg), the choice of 75 lines is a little arbitrary, but it's a good indicator for a code-smell 💩.

> Personally, I would aim far lower than 75 lines, but this would likely result in more architecture and composition - something that might be off-topic for a style guide.

---

## 👓 What Needs Clarification: Functions Are Not Methods, But They Are Still Useful

In one code example, [found in the Angular style guide](https://angular.io/guide/styleguide#rule-of-one), a plain JavaScript function is shown as part of the "bad code" to avoid. 

In the "good code" solution, the function is replaced with a Service class method.

I don't think the intention here was to say JavaScript functions are inferior to class methods, but... this is the _only_ use of the `function` keyword in the **entire** style guide 😲!!

Looking closer at the example code, it becomes clear why the function was replaced with a Service class method.

The author wanted to take advantage of [Dependency Injection](https://angular.io/guide/dependency-injection) and use the [HttpClient](https://angular.io/tutorial/toh-pt6) to request data from an API 😅.

However, I think a point needs to be clarified here:

> **We should embrace using native JavaScript functions to encapsulate common operations, especially ones that don't mutate state and have few parameters (dependencies).**

One common use case I find for JavaScript functions is when creating an [ES Module](https://hacks.mozilla.org/2015/08/es6-in-depth-modules/) that contains small, reusable functions which perform validation, data transformation, or object creation.

If these functions are ["pure"](https://en.wikipedia.org/wiki/Pure_function) (they produce no side effects and always return the same values for the same inputs), then they will be easy to test (maybe the easiest code to test in our apps).

If they are easy to test and we use them throughout our applications, this will increase our confidence in the quality of our code and logic 👍🏽.

### 📌 An Example

Sometimes we create Service classes with methods that do not access any internal state.

Here's an example:

```typescript
@Injectable({ providedIn: 'root' })
export class UserService {

  validateUser(user: User): boolean {

    return user.id &&
      user.username &&
      user.enabled &&
      user.hasPaidAccount
  }
}
```

In the above code there is no use of the `this` keyword.

Inside a class method, a lack of `this` means that method can be changed into a JavaScript function.

But why would we want to use a function instead of a method 🤔?

Well, in this case, `validateUser` only depends on 1 thing - the `user: User` parameter passed to it.

We don't have a need to create an instance of `UserService`, register the type with Angular's dependency injection system, or inject it into other classes.

Instead we could place `validateUser` in an ES Module, export it, and then import it into other modules as needed 🧐.

---

It's also worth nothing that by not having access to the `this` keyword, a function is easier to trust.

We know that it isn't changing the internal state of a class, but a class method _can_.

If a function does change application state, it can only change the state of the parameters passed in - but this is **easily** testable 🤗!

---

## ✨ Conclusion

It is kind of funny 😁 how this rule is named "Small functions" when the only use of actual functions in the style guide results in their removal!

To be clear, I'm not recommending that we replace all classes with functions - there are definite benefits to using classes, Angular's dependency injection system is powerful, and it works well with classes.

I do completely agree that we should consistently aim for small functions or methods in our applications.

I **also** think the style guide could either clarify that it's recommending "small methods", or add a couple examples of JavaScript functions being used in beneficial ways, and remind developers that classes are a good tool, but not the only tool!

As always, thanks for reading 🙏!

---

## ❓ Questions

What are your thoughts on "Small functions"?

Do you find yourself mostly writing classes in Angular applications, or do you also use JavaScript functions?

Does mixing the two cause confusion, or is some inconsistency ok when we use the right tool for the right job?

What do you think is a good goal for function/method length to keep our code maintainable?

Leave a comment below!

---

<figcaption>Photo by <a href="https://unsplash.com/@anaminella">Ana Minella</a> on Unsplash</figcaption>

---

Normally, I'm blogging about [Kentico](https://www.kentico.com/), a content management system I love to use.

We've put together a list over on [Kentico's GitHub account](https://github.com/Kentico/Home/blob/master/RESOURCES.md) of developer resources. Go check it out!

If you are looking for additional Kentico content, checkout the Kentico tag here on DEV:

{% tag kentico %}

Or my Kentico blog series:

- [Kentico 12: Design Patterns](https://dev.to/search?q=Kentico%2012%3A%20Design%20Patterns)
- [Kentico CMS Quick Tips](https://dev.to/search?q=Kentico%20CMS%20Quick%20Tip)
- [Kentico EMS: MVC Widget Experiements](https://dev.to/search?q=Kentico%20EMS%20-%20MVC%20Widget%20Experiments)