Forem: Charissa Johnson

BEM - A CSS Naming Convention

Charissa Johnson — Fri, 10 Jul 2020 00:42:13 +0000

What is BEM?

BEM is an acronym for Block, Element, and Modifier and is a methodology for creating reusable CSS. BEM works by providing a pattern for naming components that makes the relationship of a components style classes to the markup more obvious. For example, take a navigation component on a web page. Some items that might be included are a nav container, a list, and list items.

Blocks

Since we're using the nav component and know that we have a nav container, list, and list items, we can use BEM to help us give these items some meaningful class names. BEM's naming structure follows a pattern where blocks are named things such as nav, container, or header. Blocks are top-level items on a webpage (or screen if you're working on mobile devices). The best way to figure out whether an item is a block is to determine if it is meaningful on its own. For example, a nav or button item is meaningful on its own. You know exactly what these items are without needing any extra context. If you're perusing some css and see .nav then you don't really need any other context. You can tell exactly what a nav is just by reading the class name.

Elements

Elements are named using a double underscore such as nav__list, container__title, and button__submit. Elements are part of a block and do not have standalone meaning. A good example to help convey what this means is to think of a list item. An li on its own has no standalone meaning. What is it tied to? Where does it go? If you see li in CSS then you have little to no idea of where the li is located in your markup and you have no idea how many li elements on the page will be affected if you edit the CSS. However, if your li is named navList__item then suddenly this element has meaning. It is important to note here that blocks can have many nested elements, but blocks cannot be nested within an element. This is due to the fact that blocks must be meaningful on their own.

Modifiers

Modifiers are the smallest units in BEM and are used to describe the behavior, states, or appearance of an item. Take the nav list items, these could have modifiers for color or hover. In BEM this would look something like navList__item--blue or navList__item--hover. Note the two dashes. This is how to denote an attribute in the BEM naming convention.

Putting it all together

Now that we know the basics of the BEM naming convention, let's see what this might look like. Using the nav example discussed throughout this post the markup might look like this:

<div className="nav">
    <nav className="nav__container">
      <ul className="nav__list">
        <li className="navList__item--blue">I am blue!</li>
        <li className="navList__item--red">I am red!</li>
        <li className="navList__item--hover">I have a hover state!</li>
      </ul>
    </nav>
</div>

Now that we know what our HTML looks like, we can design some CSS classes. Based on the names created, the CSS may look something like this:

/* Block */
.nav {
  text-decoration: none;
  background-color: white;
  color: #888;
  border-radius: 5px;
  display: inline-block;
  margin: 10px;
  font-size: 18px;
  text-transform: uppercase;
  font-weight: 600;
  padding: 10px 5px;
}

/* Element */
.nav__ul {
  background-color: white;
  color: #fff;
  padding-right: 12px;
  padding-left: 12px;
  margin-right: -10px; /* realign button text padding */
  font-weight: 600;
  background-color: #333;
  opacity: 0.4;
  border-radius: 5px 0 0 5px;
}

/* Modifier */
.nav__li--blue {
  color: blue;
  font-size: 28px;
  padding: 10px;
  font-weight: 400;
}

/* Modifier */
.nav__li--red {
  border-color: #0074d9;
  color: white;
  background-color: #0074d9;
}

/* Modifier */
.nav__li--hover: hover {
  border-color: #ff4136;
  color: white;
  background-color: #ff4136;
}

Imagine that the CSS was the first thing you looked at in a project. If you saw CSS like what's above, it would be easier to read those classes and know exactly what it is they're supposed to be styling. This is one of the biggest benefits of BEM. BEM allows you to design your code in such a way that both your HTML and CSS make sense separately, as well as together.

Wrap up

Keep in mind that this isn't a perfect example, it was designed in a way that made the most sense to me. That is exactly how BEM should be used. There is not a one-size-fits-all approach here. If you, or your team, prefer different class names and structure, then use whatever seems best suited to your project. The most important part here is keeping the code clean, readable, and maintainable. When your CSS makes sense, it's much easier to go in and make edits and know exactly what it is that you are changing without having to fight with a bunch of different cascading rules.

Pair and Mob Programming: Best Practices

Charissa Johnson — Sun, 24 May 2020 23:14:53 +0000

We've all heard of pair programming, that concept where two or more programmers work together on a solution. The term "pair programming" evokes a lot of reactions when you first broach the subject with developers. Hopefully, this article can help put some of the negative connotations around pair programming to rest.

Pair Programming

So, what does effective pair programming look like?
Pair Programming consists of 2 programmers where one is a navigator and one is a driver. This pair works together on one story at a time, where one programmer is a navigator and the other is the driver.

Mob Programming

Mobbing is similar to pairing, except that there is one driver and many navigators. In mob programming, everyone works on one story while one person drives and everyone else navigates. Mob programming is best used when only one person has experience in something and needs to catch the team up, or when the team is learning something new together. Otherwise, pair programming is a better approach.

Roles

There are two roles, as you've no doubt already noticed in pair and mob programming. These roles are the navigator and the driver. It is important that the people in these roles remember that they are a team and are working together to complete a task. We'll break down what these roles entail below.

Driver

The driver is the person who is at the keyboard, typing the solution. As the driver, you type what the navigator says and don't "run away". Running away is the term used for a driver who stops listening to their navigator and just starts typing their own solution. It can be hard not to do this as the driver. Sometimes because the navigator doesn't know what to do, sometimes because the navigator is going too fast and it's hard to keep up. This is where it's important to signal overwhelm. This can be done many ways, such as simply lifting your hands from the keyboard, simply saying "let's slow down" or any other signal agreed upon between navigators and drivers.

Navigator

As the navigator, it's your job to explain the solution and help your driver to code it. Navigator roles are best taken by the more experienced programmer per solution. As a navigator you want to make sure to find the level of your driver. Don't direct experienced programmers as if they are novices and don't direct novices as if they know (or should know) everything. It is also important to pay attention to cues from your driver. If you notice them feeling overwhelmed, then know that it's time to adjust your approach or take a break.

Timing Tradeoff

It can be hard to pay attention and stay focused during pairing and mobbing sessions. Working for too long can lead to fatigue. On the other side of this coin, sessions that are too short can lead to too much overhead while switching drivers. A few ways to remedy this are to take frequent breaks and/or switch roles as often as makes sense or when possible.

Breaks

Breaks are an incredibly important part of any work day, but they're especially important in pair and mob programming. It's not uncommon for team members to be used to staying at their desks all day, which can lead to them feeling guilty if they aren't actively programming. This is where it needs to be said that breaks are important. They keep everyone involved, allow time to absorb the current work and think about the solution. They leave room for new ideas to incubate and can prevent mental fatigue. Furthermore, pair and mob programming become less effective as team members lose focus.

Discussing Code

You might have read about the role of driver and thought to yourself, "so I just have to type what I'm told, no matter what"? The answer to that question is a solid no. If you had to blindly type everything the navigator told you to type then that completely erodes the concept of teamwork. While drivers and navigators will not always agree on the solution, it's important to be respectful and remember that everyone deserves to be heard. A good way to mediate this is to argue in code. Meaning that you can show brief examples in your code or on a white board to discuss the solution. This helps everyone to think through the problem at hand and come to an agreed upon solution.

Convincing your boss or your team

So, why should you use pair or mob programming? Pair programming helps prevent mistakes, gets work done faster, and leads to better design. It is also excellent for mentoring and onboarding new developers. It helps build communication skills and foster teamwork. Plus, it's often a lot of fun, but that one may be my personal opinion.

If you want more information on pair programming, I'm always happy to answer questions. I can be found at @DevCharissa on twitter. You can also watch my talk for Women Who Code DFW on youtube for a more in-depth version of this article.