Lightning Talk: ClangFormat Is Not It - Anastasia Kazakova - CppCon 2023
Вставка
- Опубліковано 8 кві 2024
- cppcon.org/
---
Lightning Talk: ClangFormat Is Not It - Anastasia Kazakova - CppCon 2023
github.com/CppCon/CppCon2023
Sometimes things are not what we think of them. But we keep using them based on our perception. ClangFormat is a widely used tool by the C++ community. Join me to explore the typical delusions around it.
---
Anastasia Kazakova
As a C and C++ software developer, Anastasia Kazakova created real-time *nix-based systems and pushed them to production for 8 years. She worked as an intern in Microsoft Research, Networking department, outsourced in Telecom, and launched the 4G network. She has a passion for networking algorithms and embedded programming and believes in good tooling. With all her love for C++, she is now the Product Marketing Manager on the JetBrains C++ tools and .NET marketing teams.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
UA-cam Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp - Наука та технологія
My opinion on the main reason for clang-format’s shortcomings mostly boil down to the tool not being opinionated enough. Although the fact it doesn’t use the clang AST was quite surprising.
not using the AST makes it fast, and means it can work on small snippets of code (that form part of a say git diff where the headers and full source isn't available)
don't underestimate the power of the TokenAnnotator, this classifies the token so we get determine the type of construct the {} or () form.
I was hoping to hear about some alternatives at the end. Any suggestions guys? Also how do I enforce naming style like snake vs camel case? I liked that Java was opinionated on this but seems like C++ doesn’t have single standard.
we use clang-tidy for that.
Shots fired!
It's a pita is what it is
So basically.. clang format has a bug. I'm sure they can fix this specific issue. The only real good argument i'd say is that the clang format config file isn't properly backwards compatible; that is the real annoying part; but just requires some maintenance. I'd take consistent formatting with 1 or 2 tiny mistakes any day over no proper formatting at all.
This is more than a bug. If they don't generate an AST that's a fundamental shortcoming
To be clear: I'll take it any day over nothing, but it sounded like *maybe* we have options?
1:53 - Clang-Format options have a life span, they tend to start as booleans true/false, later become enums Always/Never/BeforeXX/AfterYYY, then often later become structures
BreakStyle {
AfterXXX
BeforeXXX
Indent: 4
}
At every stage Clang-Format supports the migration of one to the other to the other, we don't break compatibility, we fix bugs, which might cause your code to reformat
but we don't break compatibility (unless there is a very good reason)
The "backwards compatible" is levelled at us from time to time, actually mostly its because we've improved the TokenAnnotator to classify more types, from time to time its because say a bug is fixed or we've introduce some new concept (maybe concepts) and it interfers with other formatting a little. However every change goes in with a unit test and we really really push back at people changing unit tests. If something has regressed its more often than not due to us not having the unit test in the first place to enforce it.
There is the theoretical issue of how to format code that failed to be parsed
As one of the maintainers of clang-format this presentation is factually incorrect in a number of areas. Its a low blow on a project
that relies on the good will of a few developers who provide functionality used by 10,000s if not more.
Thank you for your work on this tool, it's invaluable.
Thank you, thank you, thank you! I can not imagine my work day without clang-format. This talk was bad, and statistics presented here are bs... every company I worked in in the past 10 years had clang-format in it's codebase, I do not care about some rando github repos.
spot on assessment of clang-format!
When you are making confusion (by using clang format here), you are not helping.
uses bad code
-> gets bad results
Writing `A < 1 + 2 > (3 + 4)` is a weird way of basically doing `A < 1 || 2 > (3 + 4)`, which is formatted correctly
Exactly.. if clang-format is having trouble so will ever other developer who comes back and look at this code later.. would you ever put code like that into a flight control system, pace maker or UK postal accounting software !! I know I wouldn't.
I don't understand the obsession with formatting because 1. there is not one single rule that can be applied everywhere, and 2. we are humans, not robots. Even if you enforce whatever guidelines, everyone still has their own way of doing things. It may actually be helpful if you can see from the style who wrote what code. Autoformatting just throws away all that information.
You should be using Blame to find out who wrote code, not code style
I suppose I see it as a means to end unproductive argument about whose ideas are best about formatting. At the end of the day, we are just going to select one and move on.
git blame has a mechanism that can exclude certain commits that were solely for whitespace changes, so either use clang-format from the word go, do the entire source code in one go then always enforce it. that way no blame information is ever lost
The problem with humans is everyone as you say does it their own way, formatting can help bring everyone way to be the same way, meaning its as easy to read someoneelse code as your own, becuase it looks like your own (to a certain extent)