Hacker News Reader

Comment by odc | Hacker News Reader

I love Go's letter casing. It's such a neat way to remove cruft.

It also adds cruft. Public struct members JSON usually needs to be converted to lowercase. Hence the stuct tags.

JSON is just one tiny part of most programs, sitting on the edge where the program interacts with other programs; it doesn’t permeate the entire codebase.

Structure privacy, OTOH, does. Count me in as someone who really enjoys the case-based approach. It’s not the only one which could work, but it does work.

The single most productive habit I picked up int the last few years is to always use exactly the same name for the same entity across source files, configs files, database entries, protocol fields, etc.

That’s funny, I did it your way for years and ended up considering it a big mistake.

Today I use idiomatic names - MyName in Go, myName in JS/JSON, my_name in SQL. There are many reasons but generally speaking, for me, it’s less effort and code is more readable.

Curious what your rationale is?

I just ran into this earlier today - it makes navigating code with grep more difficult.

I had a YAML file using `some_property_name`, which was turned into `SomePropertyName`, and it's a small annoyance. It's not a huge deal, but it adds friction where some languages have none. (Or alternately, getting reordered in a separate system like `property_name_some`.)

The issue that I ran into is dealing with lot of code across different languages, like plpgsql, go and JavaScript.

Especially with database code, something that's fine in Go, like EmployeeID, ends up being employeeid in SQL. You can use underscores in Go but that can trigger other behaviours. If you mix your own JSON with JSON from other sources, you get inconsistent capitalisation. And so on.

And when you have hundreds or thousands of identifiers like this, it gets really hard to read.

You can of course capitalise in SQL - even though it's not semantic - but that becomes inconsistent, too. And then of course the lifecycles of each of these things can be different, which adds another layer of complexity - maybe you refactor your Go code before you upgrade the database, so you end up with two identifiers anyway.

Ultimately I switched to using idiomatic names everywhere, and I really haven't looked back. The boundaries between these systems tend to be pretty clear, as mentioned by someone else, so finding things shouldn't be hard regardless of what they're named.

It's certainly takes slightly longer to deal with idiomatic names - but you read code way more than you write it, and it's easier to read idiomatic code.

Ease of grepping is one benefit, but for me the main benefit is the cognitive overhead when reading code.

I have the benefit of writing mostly C++ where there is really no globally agreed idiomatic naming. At $JOB we use snake_case naming for C++ functions and objects (as opposed to types), which also matches the python naming convention we use.

Snake case is not idiomatic for xml, but we still happen to use it for leaf config options.

The main benefit is reducing ambiguity to what maps to what across files. Ease of grepability is also an advantage.

I do the same way like you. My logic was that I can tell where the value is coming from. I would use the same type but different name.

Is it coming from a client via http? Then it needs to be checked and saved

The database? then it has an id field which could be null in other cases.

Or I just create a new instance?

Naming things is hard tho, sometimes I do think I should just name them the same and stop caring. I'm not sure if I gain productivity but it gives me some comfort that I can instantly tell the source of the data.

And database col name, and validation and...

The moment you integrate with a third party your US centre zip_code field is suddenly coming over the wire as postCode. The conversions are going to go on, at least in go I can define all of that conversion with ease in one place.

> It's such a neat way to remove cruft.

I don't disagree, the problem I have with it is, I have to pay for that up front and have to factor it into my design immediately. This also combines with the fact that the namespace is very flat with no heirarchy, so, choosing good public names is something I feel like I spend way too much time on.

Go is the only language that causes me to pull out a thesaurus when trying to name methods and struct members. It's kinda maddening. Although, after going through this exercise, I end up with code that reads like English. I just wish I could refactor my way into that state, rather than having to try to nail it up front.

>I just wish I could refactor my way into that state, rather than having to try to nail it up front.

Procrastination looms. :o

Choosing names is something that often is in the bucket of oh I wish I had thought a little more before sharing these names.

ChatGPT is really good at suggesting 20 names for <vague description of thing>. Try it out!

Go's semantic use of case is objectively bad because most of the worlds scripts do not have the concept of it. For example ideographs, as used in eastern countries, do not have capitalization. This means programmers in many parts of the world cannot express identifiers in their native tongue.

It looks like something was lost in the middle of your comment. You open with something about it be objectively bad, but then it jumps to something about how it is subjectively bad. What was omitted?

How is "i cant name variables in my native language" subjective?

I don't really think the sarcastic tone was called for, but the previous poster is right. "I can't name variables in my native language" is objective, but whether or not that's bad is subjective.

Very true but “bad” is always subjective so at least they came up with an evaluation that is binary — either you have capitalization in your language or you don’t, either the analogy fits or it doesn’t.

(Some linguist will point out that Bongo-Bongo has half-capitalization, or half has capitalization).

True, as a non-native speaker: naming variables in a native language (that's not English) is objectively bad.

So if you have a concept that doesn't have an equivalent in English you just kinda translate it and add a comment for other people of your language to understand what it is?

Sure. And for a concept that's so foreign there is no English equivalent, I hope there's plenty of documentation. I mean, to each their own, but for me, a software team using native language for variables is a red flag.

You could also transliterate it into the English alphabet. Looks ugly but saves you from having to switch your keyboard layout.

Dislike it very much specially with codebases which have lots of acronyms, aka aviation. Having to change an acronym from upper to lowercase just suck.

In that case, maybe try: `_ACRNYM`

Function names with _ ? That’s not for me :)

I spent quite a few hours tracking down bugs due to miscased struct fields unfortunately. Strongly prefer explicitness over implicitness

Which IDE do you use? Mine would flag this as an error pretty quickly.

Goland. How would an IDE know that you intended a struct field to be public or not?

Any non-private usage of a private struct is a compile error.

If you're using goland, it would report this as an error as it is effectively compiling your code as you write it.

Also, autocomplete wouldn't work when you tried to use the private struct.

The casing rules are quite explicit and enforced by the compiler. A build would have immediately failed on whatever mismatch you had. A few hours and you didn't even think to try compiling it?

I'm guessing you are talking about something else entirely, like, perhaps, decoding JSON into a struct using reflection and encountering a situation where the field names didn't match? Indeed, implicitness can bite you there. That's true in every language. But, then again, as you prefer explicitness why would you be using that approach in the first place?

The rules are explicit but the actual changes in code are very small and unique to this language (or unique from the languages I had ever used). It’s one of those things that you can forget about — because it’s a small difference in code and arguably isn’t explicit.

I forget what it was, but basically my code wasn’t working the way I thought it should and it was solely due to a lowercased struct field. It happened twice where I spent at least a little while trying to figure it out.

And yeah I would guess that I tried to compile. Would be very dumb if I hadn’t although wouldn’t be the dumbest thing I’ve ever done

I like the terseness of it but having to refactor just because I change visibility is a bit stupid.

I never wrote ObjC but didn’t they use + and - (and nothing) as visibility modifiers?

Reply on news.ycombinator.com