top | item 40213585

(no title)

odc | 1 year ago

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

discuss

order

phplovesong|1 year ago

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

eadmund|1 year ago

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.

zer00eyz|1 year ago

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.

akira2501|1 year ago

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

lanstin|1 year ago

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

aatd86|1 year ago

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

Procrastination looms. :o

bbkane|1 year ago

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

hgs3|1 year ago

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.

randomdata|1 year ago

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?

metaltyphoon|1 year ago

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.

Groxx|1 year ago

In that case, maybe try: `_ACRNYM`

jjallen|1 year ago

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

randomdata|1 year ago

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?

latchkey|1 year ago

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

doctor_eval|1 year ago

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?