Are terminologies meaningful in software development? Yes, a lot! As developers, we’re continually writing code, and we do that by passing messages. Each message carries a lot of context and semantics. Therefore we’re always evolving how to do it in a better way. There is this vastly known anecdote that says that there are only : caching invalidation and things. two hard things in Computer Science Terminology is in the roots of communication, and therefore is as vital for writing quality code as writing User Stories, documentation, and even naming branches. If you care a lot about communicating effectively, I think we must use an to do so. inclusive language Inclusive writing is the usage of the language with neutrality. Inclusiveness has a positive impact on our lives, as they don’t offend interlocutors based on abilities/disabilities, age, gender, sexuality, race, ethnicity, religion, etc. It would be best to read that describes how to be more inclusive when writing. The impact of fostering more inclusive writing implies changes in how we write software. Besides, sooner or later, we see that it affects many aspects of everyday life communication. 🌱 this content guide Some time ago, regarding the came up. I got pleased that the concern of an inclusive language arrived in the master branch name in . The proposal addresses replacing the master branch name by a more inclusive one. tool I use every day for development At SourceLevel, we have opted for using main as the default branch name. Did you know you can change the default branch in your Git repositories? You can do it by both ( ) and ( ). Project Settings > Repository Repository Settings > Branches Changing the default branch of your repositories may break some tools. In the case of SourceLevel, we already support the custom default branch, and it synchronizes with GitHub and GitLab. Changing on those tools automatically replicates in our tool. Steps for changing your default branch In the examples below, I rename the master branch to main. You should discuss with your team and find the name that better suits you. Firstly, we need to rename it locally: $ git branch -m master main
$ git push origin main -u And you’re done! These two commands rename your local master branch and then push it to the remote server. It's a secure way to start, once the commands don't delete the remote master branch. Note that after changing the name to main, everyone who clones the repository gets the new default branch set. However, people who had previously cloned the repository are still pointing to the master branch. To move forward with the change, everyone in your team needs to run a . For a complete guide, I strongly recommend reading . few commands Damien Cosset’s blog post Using SourceLevel as an Inclusive Language watchdog Now that we have a more inclusive branch name, there may be references to other terms that we should avoid. They may appear in variables, methods, or even comments. So, we need to look for them the whole codebase. This part can demand lots of hard work, depending on the size and terminology used throughout codebases. Changing the existing code doesn’t prevent you or your team from using exclusive language again. What if a bot could notify you when a contravention appears? You can use the as a watchdog! grep linter Configure your .sourcelevel.yml file adding rules that look for exclusive language and suggest more appropriate terms for each Pull or Merge Requests using SourceLevel's feature. It should look something like this: automated code review engines: grep: config: patterns: allowlist: pattern: "/white[_\\-]?list/i" annotation: Do not use 'Whitelist' . Prefer the term 'Allowlist' categories: Style path_patterns: - "**/*.ex" - "**/*.exs" blocklist: pattern: "/black[_\\-]?list/i" annotation: Do not use 'Blacklist' . Prefer the term 'Blocklist' categories: Style path_patterns: - "**/*.ex" - "**/*.exs" enabled: true After pushing it to the main branch, SourceLevel can help you achieve a more inclusive language throughout the codebase! In short Using an inclusive language is crucial for fostering a diverse culture. Git has changed the naming conventions to be more language-inclusive, and so you should change. Our development tools, like GitHub and GitLab, already supports the change. SourceLevel deals very nicely with repositories that changed the master branch to a more appropriate word. Besides, you can use the grep linter the look for exclusive terms contained in the source code. As the inclusive language gap may happen in other aspects of our lives, have you already thought about them? Raise the discussion in your team and use the tools to favor a more inclusive world 💚! Previously published at https://sourcelevel.io/blog/git-linters-and-sourcelevel-how-tools-enable-a-more-inclusive-language-and-diverse-culture

Golang Linters: How they Analyze Code, Formatting, Complexity, and Comparison

Pull Request Checklist: What You Need to Do Before Assigning a PR to Someone

SourceLevel - PRs Metrics and automated Code Review

SourceLevel · All-in-one Data & Analytics for Engineering Teams

How Different Tools Enable a More Inclusive Language In Software Development World

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

7 Git Practices to Start Using in Your Next Commit

10 Expert Tips for Improving Code Reviews: A Guide for Developers

13 Tips for Better Pull Requests and Code Review

4 Data Management APIs for Better and Faster Innovation

4 Ways Software Engineers Organize Their TODOs

5 Critical Topics Covered at Once: Code Review Practises You Cannot Miss

7 Git Practices to Start Using in Your Next Commit

10 Expert Tips for Improving Code Reviews: A Guide for Developers

13 Tips for Better Pull Requests and Code Review

4 Data Management APIs for Better and Faster Innovation

4 Ways Software Engineers Organize Their TODOs

5 Critical Topics Covered at Once: Code Review Practises You Cannot Miss

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps