We started to see the benefits of Black before we had even completed the integration.Reuters | Updated: 14-03-2023 23:53 IST | Created: 14-03-2023 23:53 ISTĪ Russian Su-27 fighter jet intercepted and struck the propeller of a U.S. The result is a reformatted, up-to-date, feature branch ready for merging. This allows the developer to keep in all feature changes they have made, which they can subsequently re-format with pre-commit run - all-files. This isn’t a post about git merge strategies, but the above command merges in the now blackened develop branch to the developer’s local feature branch, taking all the blackened code, but favouring the developer’s local changes in the case of any conflict. (Confusingly, this is not the same as the ‘ours’ merge strategy). Thankfully, git had us covered using the recursive merge strategy with the ‘ours’ option. For example, where Black has formatted a function call that was previously over two lines onto one line, and a developer has updated that same call to pass in a newly named variable.
When implementing far-reaching changes such as with Python Black, this can cause a lot of merge conflicts for developers working on the project simultaneously. Our develop branch is protected and requires that all feature branches are up-to-date with the latest commit before merging. We manually reviewed all the changes on the fast code, and were confident that combined with our comprehensive test suite and eagle-eyed QA team we’d be ok. First, running in safe mode over everything it could and then running fast on the rest. This ended up being about 25% of our codebase, so the bulk reformatting was ran in two stages.
#Black formatter code
One caveat here is that Black uses Python 3 to do this, so we came across areas where due to Python 2 breaking syntax (think print), Black was unable to confirm the code was safely reformatted. Safe mode was however very reassuring when implementing this on the existing codebase. Black notes that this is however a temporary measure, so we run with it off. In safe mode Black will check that the reformatted code produces a valid AST that is equivalent to the original, so you can be sure it hasn’t inadvertently changed the behaviour of your code. Running the tool generated a 40,000 line diff! There are two ways to run Black, -fast or -safe. Our core backend Python API codebase is a 200,000 line monolith. Implementing Black on an existing codebase was the most time consuming part of this task. Once we agreed to use Black, it was a case of formatting the existing codebase, and then running with it. Python Black has a set of rules and it implements them without question. That’s it! The best part about this was not having to agree any standards as a team, no discussing optimal line length, no single quotes vs.
#Black formatter how to
The main benefits of this are the time saved having to think about how to format your code, and the time saved in pull requests from your colleagues suggesting their code preference. In essence you write whatever code you want with any formatting you like, and when you commit, a pre-commit hook kicks in and re-formats your code automatically to a consistent style. If you write software, or work with people who write software, then this is hopefully starting to sound appealing already. This introductory paragraph from the black repo sums up perfectly why we wanted to implement such a tool “speed”, “freedom from nagging”, and “saving time and mental energy”. You will save time and mental energy for more important matters. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting.
By using it, you agree to cede control over minutiae of hand-formatting.
We wanted to reduce the time spent correcting each other and discussing code formatting while continuing to achieve a consistent, quality code style.īlack is the uncompromising Python code formatter. However, agreeing on and enforcing these standards can be a productivity drain when writing code, during code reviews, and when on-boarding new staff. Readability of a codebase can affect the long term productivity of a team which is why organisations often agree standards amongst developers to ensure consistency. Implementing Python Black on a Legacy CodebaseĬode formatting is a contentious but important subject.
0 kommentar(er)
