ChromiumOS Developer Guide, Programming languages and style | Hacker News Reader

ChromiumOS Developer Guide, Programming languages and style

chromium.googlesource.com

73 pointspjmlp55 comments

> Optimize for the reader, not the writer

> 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.

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.

Yes, I also find 2 spaces for indentation to be completely unreadable. I am not sure it has anything to do with age.

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.

Tabs for indentation, spaces for alignment. This is my take.

I only can use it on personal projects, as most places I worked in use spaces.

https://flinhong.github.io/images/201607/tabs-spaces.jpg

Alignment is pretty overrated tbh

Great if nare the two shall meet, but what happens when alignment is dependant on spacing (eg. fancy code comments)?

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.

How do you count tabs towards line length for auto formatting?

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.

For me 2 spaces is enough to read code and 4 spaces make code unnecessary wide which makes it hard to read.

Which is exactly the case for tabs, so everyone can render the tabs as wide (or narrow) as they want!

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.

Or there should just be a character that means "one indentation" that editors can use!

Yeah... I mean, how to represent that type of indentation, I know it's the Tab key on the keyboard, but what to call such a beast.

Yes!

Use tabs and allow people to pick their own spacing

Also good for accessibility

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?

Not really, because it would screw up alignment (tabs can only be used for indentation, alignment needs spaces).

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).

I think we can all agree to 3 spaces then?

I find 2 spaces far more readable so it’s subjective and we can’t just declare that these rules necessarily conflict.

It's a Google-specific legacy mistake. IIRC, they even do (used to do?) two-space indentation for Python.

Some Google python-based projects, like oss-fuzz, are still indented with 2 spaces, which is a huge pain.

https://google.github.io/styleguide/pyguide.html#34-indentat... suggests that they use four spaces.

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).

https://chromium.googlesource.com/chromiumos/docs/+/HEAD/sty...

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.

What's old is new again, it feels like 1998 and I'm sure times before that.

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.

ofc the number 1 comment is a tabs/spaces comment lol

Can I ask how old you are?

I pose this question sincerely, as I'm over 40 and still prefer 2-space tabs myself.

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 :-).

Interesting that they use auto-formatting for Python using the Black tool, is this common elsewhere?

https://chromium.googlesource.com/chromiumos/docs/+/HEAD/sty...

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.

clang has tooling for this and includes a google specific style.

Of course rust has a built in one, so yes.

I for one cant believe that no major company like

- dropbox

- Mozilla

- nextcloud

- Backblaze

has forked ChromiumOS and replaced the backends with their storage. That would be wonderful.

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.

Okay? My point was that

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.

Except it hardly matters when most stuff are actually drivers running in userspace, aka binary blobs.

VSCodeBook. They already have Codespaces which is web-based anyways.

They use laptops for backends?

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.

https://developer.chrome.com/docs/extensions/reference/fileS...

> - Mozilla

https://en.wikipedia.org/wiki/Firefox_OS

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.

Nothing surprising there. Of course most of the choices remain backwards, but it's not as bad as the base Google guidelines.

What choices are backwards?

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.

> clippy is used a linter

Nice evolution from an annoying dialogue in MS Office. /s

This is pretty outdated, at least some things are not correct anymore

Reply on news.ycombinator.com