Back to all blogs

Bootcamp Week 2 – CSS Naming Conventions and Code Conflicts

A screenshot of CSS for a Header using BEM methodologyTwo deers hitting horns with eachother.Scrabble letters that spell out CSS.

This week’s bootcamp focus was on CSS and pair programming. We started with a solo CSS tutorial, which served as a great refresher, and then applied styling to the HTML structure we built in Week 1 while working in pairs. On the second day, we continued collaborating by recreating a new Figma design using HTML and CSS.

Naming Conventions

In preparation for this week, I revisited some areas of CSS I felt rusty on and came across BEM (Block Element Modifier), which also came up during the bootcamp. BEM is a methodology that helps create reusable components and encourages consistent code sharing in front-end development, especially when working with CSS.

Previously, when writing CSS, I often mixed reusable classes with direct element targeting. This led to problems, such as having to write selectors like:

.container > img

With BEM, I can instead use classes like the below, making the styling more reusable across similar components:

.container 
.container__img

During pair programming, BEM proved especially useful. It made it easier to identify which classes my partner was using and reuse them consistently in my own styling, and vice versa.

Code Conflicts

Code conflicts were something I really wanted to understand better before starting this bootcamp, as I’d always wondered how to avoid writing the same code as a partner and then having to resolve conflicts.

On Day 1, we did a short pair programming task in the afternoon. We branched off from the GitHub repo - one branch for the header and one for the main section. We ran into a few conflicts, mostly around class names in the HTML files and the layout in index.css. Since we were working side by side, we were able to discuss and resolve these issues together. Experiencing conflicts for the first time with a partner made me think more critically about how to prevent them.

On Day 2, I tried a different approach. Similar to how components are built separately in React, I created GitHub issues for each HTML and CSS component that needed structuring and styling (something I usually do when working independently). From there, we branched off to tackle individual issues. To minimise conflicts in the shared index.css, we each created our own CSS stylesheets. This approach worked well, and the only minor conflicts we faced were around the placement of style links in the HTML file when merging back into the main branch.

In reflection, one improvement for Day 2 would have been to set up global styles (such as fonts and colors) in the initial branch before splitting off. Even so, I was pleasantly surprised when I committed changes and had no conflicts!

Overall Thoughts and Learnings

This week was a great refresher on CSS, and it was also my first time experimenting with transitions and animations (which I feel should be used sparingly). Looking ahead, I plan to revisit some of my previous solo projects and improve them by implementing the BEM methodology. I’ve also gained a clearer understanding of how to approach pair and group programming in the weeks to come.