6 ms·
I love Go's letter casing. It's such a neat way to remove cruft.
by odc 2y ago
I love Go's letter casing. It's such a neat way to remove cruft.
- metaltyphoon 2y agoDislike 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 2y agoIn that case, maybe try: `_ACRNYM`
- metaltyphoon 2y agoFunction names with _ ? That’s not for me :)
- phplovesong 2y agoIt also adds cruft. Public struct members JSON usually needs to be converted to lowercase. Hence the stuct tags.
- eadmund 2y agoJSON 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.
- gpderetta 2y agoThe 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.
- doctor_eval 2y agoThat’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?
- __float 2y agoI 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`.)
- doctor_eval 2y agoThe 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.
- gpderetta 2y agoEase of grepping is one benefit, but for me the main benefit is the cognitive overhead when reading code.
- zer00eyz 2y agoAnd 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.
- jjallen 2y agoI spent quite a few hours tracking down bugs due to miscased struct fields unfortunately. Strongly prefer explicitness over implicitness
- latchkey 2y agoWhich IDE do you use? Mine would flag this as an error pretty quickly.
- jjallen 2y agoGoland. How would an IDE know that you intended a struct field to be public or not?
- latchkey 2y agoAny 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.
- randomdata 2y agoThe 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?
- jjallen 2y agoThe 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
- akira2501 2y 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.
- aatd86 2y 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
- lanstin 2y agoChoosing names is something that often is in the bucket of oh I wish I had thought a little more before sharing these names.
- bbkane 2y agoChatGPT is really good at suggesting 20 names for <vague description of thing>. Try it out!
- hgs3 2y agoGo'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 2y agoIt 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?
- from-nibly 2y agoHow is "i cant name variables in my native language" subjective?
- bigstrat2003 2y agoI 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.
- langnutty 2y agoVery 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).
- groestl 2y agoTrue, as a non-native speaker: naming variables in a native language (that's not English) is objectively bad.
- doctor_eval 2y agoI 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?