These conflict in the C++ guide (as well as shell). As I’ve aged, 2-spaced code doesn’t provide the necessary contrast for me to easily read & scan code, but rather than picking a larger number or using tabs so users can configure the value, a low, hard-to-read number was chosen.
Like most of us, I've had this discussion an infinite number of times, never reaching an adequate agreement.
I myself have always used 4 spaces for C++ codebases. Spaces provide fixed width and consistency, regardless of the code editor. Tab proponents say that the power of tabs is that they can be configured. Thing is, I don't want to configure them everywhere I go, and I change stations a lot. Think also of code viewers: non-logged in GitHub defaults to a 8-spaces tab width, which is enormous and code becomes too wide to read without horizontal scroll in a non-ultrawide screen.
Also, people are clumsy. I'd wish this was not the case, but that's the world we live in, and people (I'd even say MOST people) are clumsy as hell and will somehow mix spaces with tabs.
Long live the glorious and sweet dictatorship of opinionated, unconfigurable code formatters. Whether they impose 2 spaces, 4 spaces, or tabs, I don't care. Code getting automatically formatted in a consistent style across all teams and contributors, that's bliss.
(I myself actually believe that tabs for indentation + spaces for alignment would be the best of both worlds, but never tried to enforce it in my projects)
I’ve set my preferred `tab-width` as a user style & it works just fine. I’ve also raised the issue on Bugzilla to make configuration a lot more visible/easy. This is still preferred IMO to being stuck to specific values.
It's not just age, plenty of people find 2 spaces hard to read. Thus the only logical choice for indentation is tabs. That way every reader can pick the size that is good for them.
We can continue using 2 spaces and configure editors to show those 2 spaces as your desired indentation. You can also use tabs for that, but it feels like that ship sailed over 30 years ago.
I don't, I think that line length limits are typically not a good idea and thus I don't like hard limiting them. Now obviously arbitrarily long lines are no good, I'm not advocating for people to write 300+ char lines. I'm just saying that sometimes there's good reasons to (slightly!) go over the "limit", for example shortening the variable name "users" to "usrs" to make a n+1 line fit into the n char limit would be a terrible idea. And also when this topic comes up then typically people implicitly think about the 80 char limit, which is just way too restrictive and has no reason to exist anymore, it's not 1980.
The limit on what constitutes a reasonable line length is a bit subjective but I'd say that well written code rarely goes above ~120 or so. Depends a bit on the language, some just have more boilerplate than others. But instead of making that a hard limit I'd warn above that number so actual people can decide if it makes sense there or if a rewrite is in order. Auto-formatting is great and all, but ultimately a human should have the last decision.
Though if you force me to pick a value, then it's 4 because that's the sanest choice for like 95-99.9% of all people.
Editors should just allow you to configure how 2 spaces before code are displayed. It would have the exact same effect. The tabs ship has sailed. There's no reason editors can't represent 2 spaces the same way as tabs.
Can’t a sufficiently elever editor render leading spaces with any (e.g) 200% width and thus solve the problem of configurable indent width without the need for tabs?
Yes I’m only considering indentation now. Tabs vs spaces for indentation feels like it has reasonable arguments both ways but tabs for alignment just feels wrong tbh. Never even considered it a possibility in source code (and never saw it in the wild).
The ChromiumOS Python style guide notes the difference between Google's public Python style guide and their internal one.
> New projects should use that unmodified public Python Google style guide (4 space indent with methods_with_underscores). Historically, we adopted a style that was congruent with Google internal Python style guide (2 spaces with MethodsAsCamelCase).
This is such a tired issue, why can't editors be configured to display two spaces as your preferred indentation?
Why are we still having this meaningless discussion in 2023? Adding this functionality to editors shouldn't be that difficult and we can end this discourse.
I use that indentation style for labels, including public:, private:, protected: and case labels.
For everything else, I indent twice, but I have a habit to compress double-indentation in my source code into a single character code by pressing the Tab key only once.
I do not believe that anyone can argue that 4-space indented code is not easier to read than 2-space indented code, when that is the only difference in formatting between them.
On the other hand, when the style rules also impose a very short maximum code line length, e.g. of 80 characters, then I agree that in such cases 2-space indenting is a superior choice, because the slight decrease in readability is compensated by a greater increase in readability due to a much less frequent need to break long lines.
When I write for myself, I prefer 4-space indenting, but together with a greater maximum line length.
Indeed, the reason I switched to 2 spaces decades ago is for density - to fit more on the screen at a time, particularly if there's lots of nesting (which is often the case in the code I read). BTW I haven't seen code that diligently sticks to 80-character lines since the days of dot matrix printers :-).
I guess it's interesting that they're using Black over their own code formatter (YAPF) but since it's an open source project maybe that's fine?
If you were asking about Black specifically, it's very popular:
> The following notable open-source projects trust Black with enforcing a consistent code style: pytest, tox, Pyramid, Django, Django Channels, Hypothesis, attrs, SQLAlchemy, Poetry, PyPA applications (Warehouse, Bandersnatch, Pipenv, virtualenv), pandas, Pillow, Twisted, LocalStack, every Datadog Agent Integration, Home Assistant, Zulip, Kedro, OpenOA, FLORIS, ORBIT, WOMBAT, and many more.
> The following organizations use Black: Facebook, Dropbox, KeepTruckin, Mozilla, Quora, Duolingo, QuantumBlack, Tesla, Archer Aviation.
Making a fork of ChromiumOS is easy, the hard part is getting laptop makers to use it. If you fork Chrome you lose all the integrations with Google services and those are valuable to users. Think auto translation, Google account sync, other stuff.
Personally, I think Microsoft would have the best chance at this. They've been trying forever to get Windows to fit into a smaller footprint and failed over and over (Windows 10X, S Mode...).
They've got the browser, they've got the Sync integration, they've even got some Android apps (or, well, the Amazon Appstore, but best attempt?) They've even got the Win32 support from a cloud environment (Windows 365 Cloud PC). They could just market it as "Edgebook" or "edgeOS" or "cloudOS" or "liteBook" or something similar... Just don't call it anything related to "Windows."
If they really gave it their full effort it could be interesting hardware. It would be the product of choice for IT departments to deploy in companies that use Azure AD; for employees that don't need more than a web browser, or only need a Win32 app that isn't Microsoft Office on a rare occasion. As for education, just "we're not Google" is a nice pitch in some areas.
I think one thing putting Microsoft off though is that launching a non-Windows-based desktop OS is daunting; and also, one of the dirty secrets about how Chromebooks manage to get so cheap is they use the cheapest ARM processors with ridiculous amounts of binary blobs patched in that will never go upstream, so kernel updates are almost nonexistent (thus why many Chromebooks, even the one I bought from Walmart for $110 last week, have a ~5 year end-of-life). For Microsoft, maintaining customized kernels for each device that will never see an update, for many years, and basing a device's lifespan based on that kernel is antithetical to the design of Windows. Microsoft wants to ship one Windows to everyone, with an objective End-Of-Life standard, and relatively high-quality drivers; not a device-specific Windows, with a device-specific EOL, with binary blob drivers that merely hit the level of "functional on this one weird kernel".
> one of the dirty secrets about how Chromebooks manage to get so cheap is they use the cheapest ARM processors with ridiculous amounts of binary blobs patched in that will never go upstream, so kernel updates are almost nonexistent
I don't think that's actually true? For starters, the majority of Chromebooks are x86 machines, even most of the cheap ones. But more to the point, AFAIK Chromebooks, even ARM Chromebooks, are maintained mainline/upstream in linux. This is surprisingly hard to get a good citation for, but see ex. https://github.com/torvalds/linux/blob/master/arch/arm64/boo... which is device tree stuff for... honestly the code names confuse me, but I think kukui, jacuzzi, and fennel are all names for Chromebooks (or boards in Chromebooks, I think).
Just like on Android, there is Linux kernel, and then there are the stable ABI Google specific driver frameworks with OS IPC that will never be part of upstream.
> one of the dirty secrets about how Chromebooks manage to get so cheap is they use the cheapest ARM processors with ridiculous amounts of binary blobs patched in that will never go upstream, so kernel updates are almost nonexistent
doesn't seem to be true. Google doing its own thing in userspace is separately annoying to me but actually an advantage in terms of keeping the machine's kernel up to date.
You wouldn't need to fork it. Any of those companies could integrate their thing the same way that Google Drive is integrated into ChromeOS. Whatever their reasons are, it's not being stopped by anything that would be fixed by forking the project.
A bit unfortunate that Google’s Dawn missed the train for developing new projects in Rust, by just a few years. Might have been an interesting collaboration with Mozilla on the WebGPU implementation.
Random stuff banned for random reasons (main ones being "use our silly verbose and limited library instead", "templates are bad because generic programming is too complex for people outside of the A-team", "I get to set the guidelines and I don't personally like it philosophically, so I won't allow anyone to use it").
For example, no exceptions. Exceptions are a core part of the language and are fundamental to many of the features and or in maintaining invariants.
Not having exceptions means that all Google components are inherently useless in normal C++ unless they wrap them up.
The style is designed to dumb it down to make it usable by everyone who never had C++ training. For that it's valuable, but shouldn't you want your developers to be proficient with the tools they use anyway?
It seems, based on the URL fragment, this is intended to highlight the primacy of Rust in the project. I would note this is not new. The bit about Rust was added more than 2 years ago. In other words, on any other kind of article this would have a [2021] trailer in the title.
> Use only spaces, and indent 2 spaces at a time.
These conflict in the C++ guide (as well as shell). As I’ve aged, 2-spaced code doesn’t provide the necessary contrast for me to easily read & scan code, but rather than picking a larger number or using tabs so users can configure the value, a low, hard-to-read number was chosen.