And your single set method may cause you problems if you want to change one value and not the others...yes, it CAN be done with the single setter, but it may not be the BEST solution.
I am glad you said "devil's advocate"; I think that Calendar method is a dreadful bit of design.
pete stein wrote:Being devil's advocate, one possible solution is to create a get method that takes a field (such as an enum) that indicates which field's value should be returned, similar to the get method from the Calendar class. . . .
following the Java Beans specification that a get method constitutes a readable property, a set method a writable one. Quite a lot of tools work with this specification, so you should follow it. A class Datum (if there is a need to build one by yourself) needs separate properties for day, month and year, so you should generate getter and setter. Generate? Yes, the IDEs all have tools for this task.
You certainly could write an extra method that delivers the date as whole if that is a commonly needed. If the method begins with get it constitutes a new readable property.
On a side note: Java identifiers accept unicode, so you could write getMånad or getÅr.
Hauke Ingmar Schmidt wrote:On a side note: Java identifiers accept unicode, so you could write getMånad or getÅr.
I think using English is a better option. Without these comments I can't read that code. Change it to Date, year, month and day, and most programmers will be able to read the code.
Rob Prime wrote:I think using English is a better option. Without these comments I can't read that code. Change it to Date, year, month and day, and most programmers will be able to read the code.
If writing a library, especially open source - ok.
If writing an application - no. For trivial examples there are no problems. But you can't invent new words for any business term. And yes, there are words where there is no suitable one to one translation - especially as english is not an agglomerating language. So developers begin to invent english-looking words that don't make sense to native english speakers and don't cover exactly the business case and are hard to understand for the developers fluent in the original language. Lose-lose situation.
Sure, things like getKrankenkassenInfo do look funny. But it is just the convention for defining properties in Java (could be done better, like in C# or with Lombok). But there is no use to make live harder for everyone working with the code just for a random bypasser to be able to read the code.
Same for comment language.
Recently though, I have considered going back because I can be sure that Dutch identifiers haven't already been used by the API.
For instance, if there's a game you play on a map, I initially considered calling the class Terrain (which is a fairly bad compromise) and later switching to Kaart, which I'm happy with
Using other languages makes it difficult for most people to understand the intent of identifiers. I know enough German to understand Månad or År, or even to think that Kaart doesn't translate into English as Terrain, but many people don't. Specifically knowing that getMånad means getMonth rather than getManhood(!) will make it easier to follow the logic.
It's also interesting to note how far Germanic roots stretch, as Hauke and I have no issues with Ethan's code.
To clarify to Hauke, I don't know any of the Scandinavian languages, but I can read a fair amount of Norwegian and Danish, as well as a little bit of Swedish, only because I know a lot of German. I'm guessing the same goes for Campbell.
Stephan van Hulst wrote:To clarify to Hauke, I don't know any of the Scandinavian languages, but I can read a fair amount of Norwegian and Danish, as well as a little bit of Swedish, only because I know a lot of German.
I know Swedish and I am living in a town where Danish is second language although I don't speak it - written and spoken Danish differ a little bit , as can be seen here. No, those are Norwegians just making fun of the difference between written and spoken Danish.
I know it's Swedish; the German words are Monat and Jahr, which are easier to identify if you know that å is pronounced "o". And the German for "Map" is "Karte".
Hauke Ingmar Schmidt wrote: . . . That's Swedish, not German. . . .
There is no difference between written an spoken English . . . or, if I have written the English, nobody can read it to tell whether there is any difference
An example: Infinite. Based on how it looks on paper, you would say In-FIE-Nite, but you're supposed to say IN-Fin-Nit. Another example: Tough, Though, Through, Trough. They look very similar. Pronunciation? Tuff, Thoh, Threw and Troff.
Funny vid you posted Hauke, although I think it's grossly exaggerated (maybe it's a parody) xD
I took Danish class for 1 year when I was in high school. It was tough, is the least I can say :P
And I'm sorry if my code becomes unclear with the use of Swedish words, however
I do think that the clarification does the job of translating and making it understandable.
I wish I could write everything in English (I actually take notes in English, scribble down notes in English,
google in English and even think in English sometimes :p) but the programming class I'm taking
right now is in Swedish.. so I kinda have to go along with it at the moment.. I've meant to ask my
teacher why the course is in Swedish, it'd be so much easier to just use the English language and a-z
in the code. Whenever I import new code (that pertains to the course material) I have to change the native characters
because I get "illegal character" errors (the Swedish characters appear as "mojibake"/empty squares ).. it's an unnecessary pain imo, but at the moment there's little that can be
done (every week, I have to present the source and explain, would be a hassle to change everything to English,
also reading the instructions would confuse me if I changed the name of too many variables to English).
So please bear with it for now, I promise that, when I write my own code from scratch, it will have NO Å, Ä, Ö
The video is a little exxagerated, yes... but just think of the difference between Skånska Swedish and Stockholm Swedish... and add a little for Danish to the Skånska ;-) And the Danish number system is really easy and logical. You just take 1 1/2, 2 1/2, 3 1/2, 4 1/2, using their old norse names (abbreviations of them, in fact), multiply them by 20 and prefix the number by the ones missing - et voilà, you have your target number. What could be easier?