As I am working on a german only project, most of my variables are written in german language, as it would be very complicated to always think in both languages (the data is also written in the german language to the database).
My question now is: For Swift it's recommended to use camel case. But there is no further explanation for this. So, how do you use compound words?
Let's start for example with an english word, like username. Do you use username or userName? I think it should be username, because it's only one compound word.
As for english the username would still be readable, in the german language the words can get very long. Instead of "date of birth" (as dateOfBirth) you say: "Geburtsdatum" (what becomes geburtsdatum).
So actually I am questening myself: Would it be better to use geburtsdatum as it is only one compound word or use geburtsDatum, because it's better readable?
I think there is no official suggestion for this, but maybe someone else made some thoughts about this, maybe for another language with long words? If so, how do you decide when to split long words and when not?
Despite of the naming convention you choose, the pattern to naming is to separate different words, not just long words, so I think you have to ask yourself whether this are separate words?
For instance, you made an example of username vs userName: these two names of variable can actually have different meaning! I hope nobody would use them together, but first one can mean a “nickname” as on web platforms, and the latter “name of a user”, like first name or full name.
So if in German these are separate words like you would write them in a sentence, you better separate them with cases (or whatever style you choose). That’s for the general rule.
Also, there is question of how convenient to read this? For instance, if readability of a long name variable can benefit from casing few parts, it might be good to do so even though they grammatically one word.
imho on different languages use
I totally get use of native language for convenience of yourself, but I also find the benefit doubtful — stdlib and third-party APIs mostly written in English anyways… Don’t want to fire up any discussion on the topic, but the argument on why got my really confused.
The problem with this rule in german is that we love compound nouns. So (exaggerated) let benutzeridentifizierungszertifikatsnummer = 3 would be grammatically correct as a single word and, by your rule, no camel case.
I would just use camel case anyways, while not entirely following the rules of it, the readability is more important.
@flexlixrup: I think so too, but my problem is where to make the difference. I would like to have some kind of concept. Taken your example you could write benutzerIdentifizierungsZertifikatsNummer or benutzerIdentifierzungsZertifikatsnummer.
@vns: the reason why I use german language is because I use technical terms and I don't want to translate them. It would be very confusing. All technical parts like networking functionality and so on is of course only in english.
That’s why there is another paragraph about convenience for a reader The rule here is to set general guidelines on how approach naming, nobody says we should obey every word it says if that only complicates things.
As someone who doesn’t know the language at all, I’d vote for the first version with shorter blocks: from perception perspective it is easier to catch smaller pieces with the eye.
As a native speaker the first one throws me off but I’ve never seen German working well in programming for exactly this reason.
As your code is only intended to be read by people speaking German I would go for the second one just for the reason that we are used to longer words and it feels more natural. @Lupurus I now just assume that you speak german natively or at least to a high level and would say just go what feels right for you when looking at it. There cannot be a standard for every language so it should be something that looks right for the language you are writing in.
Well.... as reading your answers and thinking more about it, there cannot be a good solution. In the end, you are right: It's the best to take what feels more natural. Thanks to Xcode, there is code completion, so at least I will not make any mistakes on that ;)
Thanks anyway for sharing your thoughts (oder auch "Danke fĂĽr die Hilfe!" )
Well, actually that's a very good question. At first, I absolutely dislike snake case ;) But I think you cannot compare it, because _ makes a much bigger cut into the word then with camel case, because it almost looks like a space and it really breaks up the word.
"Geburtsdatum" and "Zertifikatsnummer" are both similiar to one thing: They have to so called "Binde-s" (it's a epenthesis), what means, that it is more then just "Geburt" (= birth) + "Datum" (= date), it has the letter "s" between it to improve the pronounciation.
While I have to admit, that I would prefer not to use camel case in this case, I would definetly use it when using identifizierungsZertifikatsnummer.
As Felix said: I should go with what feels better and what is more readable. German language is such a pain
It really is. I faced the same problem in a German banking app a long time ago (in C++). We ended up translating the fintech terms to English. We were physicists and didn't know the technical terms (in either language ) so you can imagine what translations we came up with... But still, in the code base it "felt" ok that way.
A problem arose as we became more familiar with the domain and started chafing against our mistranslations. We ended up just rolling with it - refactoring tools to even contemplate renaming variables and types weren't available at the time.
Something I've done since when this comes up - naming types and variables in domains I don't know or for concepts that are really hard to name, is try to find names that serve pretty much as a "dictionary key" rather than a value.
To give an example, in our current codebase there's a templated type that's a join between two entities. I ended up just calling it JPR. I've found this very easy to work with and it's always immediately clear what it is.
I feel like this doesn't make code harder to read, either. Obviously, if you start calling String something obscure you kind of "type erase" a reader's understanding but for a complex type that's not really the case. You need to know what this is beyond the type name and the name really only serves as an identifier at that point, not as an self-explanatory thing.
Doing this might not scale if you do it en masse - you might end up with lots of similar acronyms or such - but perhaps you can straight up translate common terms like dateOfBirth where there's no ambiguity and introduce BIZN for benutzerIdentifizierungsZertifikatsNummer where needed.
IMHO, this isn’t a problem that is strictly tied to source code. Making long compound words easier to read is something you can do in any text and the rules around this are very relaxed. To quote the German Wikipedia on the topic of “Schreibung mit Bindestrich” in the German orthography reform of 1996:
Der fakultative Gebrauch des Bindestrichs zur Verdeutlichung des Aufbaus zusammengesetzter Wörter ist freigegeben: neben Blumentopferde und See-Enge (wie in traditioneller Schreibung) darf auch Blumentopf-Erde und Seeenge geschrieben werden. Gedacht ist diese Regelung aber in erster Linie, um die Lesbarkeit besonders langer Komposita zu erhöhen (Kunststofffensterrahmen → Kunststoff-Fensterrahmen ). Aus semantischen Gründen sollten gängige (also die, die einen feststehenden Begriff bilden) und/oder kurze Komposita nicht mit einem Bindestrich geschrieben werden (z. B. Hausmeister , Tischfußball , Fahrradlampe , Boxkampf ). Aus den gleichen Gründen ist auf die richtige Setzung des Bindestriches zu achten (z. B. Fußballweltmeisterschaft , Fußball-Weltmeisterschaft , aber nicht Fußballwelt-Meisterschaft ).
I think you can use that guideline just as well for camel-casing words in source code. Sorry if this doesn’t offer any clear rules
This somehow triggers me, because I also worked on a big IoT app for a German company and the mess of mixing German and English terms was always a problem, especially when the team became more international later on. If the product is still young I would create a glossary document and start translating terms into English, tbh.
If this not feasible I would stick with standard camelCasing rules and always base the casing on the way the words are officially separated. When in doubt I would look it up in the Duden.
I also tend to do the same for English words like username, filename, setup/setUp, lifecycle/life-cycle etc. For this I also think it's valid to ask ChatGTP what the proper way of writing a term is, especially in the context of programming. I don't blindly trust AI, but for questions like this it's a useful tool.
The rule here is to set general guidelines on how approach naming, nobody says we should obey every word it says if that only complicates things.
) so you can imagine what translations we came up with... But still, in the code base it "felt" ok that way.