Develop Reference

Java naming conventions versus English language correctness [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm not sure is this right place to ask so correct me if I'm wrong.
The case is that:
one category has one code
we want to get list of codes for multiple categories
Which version is correct and why?
getCategoriesCodes()
or
getCategoryCodes()
I see this problem from two points of view, one is the English grammar, and the second one is the clean code and code meaningful naming.
Please give me your opinion which method name is better and add note is English you native language.

As both a native English speaker and a Java programmer: getCategoryCodes() is preferable. getCategoriesCodes() implies to me that I am getting multiple codes for each category, or that the codes relate to the collection of categories, rather than a code for each category.
As an example from "real" English: a car has one driver; you would refer to the drivers of many cars as "car drivers", not "cars drivers".

I would side with the clean code and meaningful naming. Nobody will judge your English in your code and also looking at the code in a month or a year will make it easier to understand if its worded correctly

There is no harm in giving names grammatical correct provided it is readable and understandable and not become very long because long names are difficult to understand.

Are you supposed to write javadoc after or before you start programming? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I think javadocs are beautiful. Clear descriptions for each method and class. Our tester can easily write unit-tests without repetitive explanations from programmers.
This is how we practice TDD at our start-up. We first sit and plan the application structure, and we start creating all the methods and classes (without programming), we add descriptions to the classes, constructors and methods with javadoc. We then ship this to our tester who write unit tests. When he is done, we start programming.
No one is actually complaining. Our tester is in love with javadoc and although he is a terrible programmer (that is why he became a tester), he can easily understand the javadoc and write junit-tests.
The thing is, most of us are newbies in a start-up. And I don't know if you are supposed to document all the classes and methods before we even start programming? My question to you more experienced programmers is: is this a good TDD approach?

TDD is useful, because it makes sure you do not miss any requirements. It ends up beings used as unit test cases, and while the programmer starts their work they need to make sure all the test cases are covered.
Testers write system & integration test cases.
coming to javadoc, ideally it should be a must. It removes code duplication/reusablity and also adds some value to system document.
Javadoc should describe the return type, input params and process being carried out within the method.

JAVA: Create boolean variable or put argument within If statement? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been running through a lot of code reviews and keep running into a situation where I see conflicting coding standards regarding boolean variables and if statements.
Here is an example of one method(1):
boolean isXTrue = getBooleanValue(DataSetX);
if (isXTrue) {
//do code
}
Here is an example of the other method(2):
if (getBooleanValue(DataSetX)) {
//do code
}
Both do the same thing and function just fine. In some cases, method 1 is a lot more readable since the boolean variable can be named something meaningful, while method 2 saves more lines and unnecessary boolean variable creations.
Maybe I am reading too deep into a simple coding standard, but I'm rather curious that if we use method 1 more often, we could have unnecessary booleans being made.
Sorry if this is a stupid question, but I wanted to get some opinions anyway :)

It's likely that the compiler will optimize both cases so that either way is identical at run time. Of course, that depends on code outside the context that you've provided.
As for the question at large: it's something that you and your coworkers or group need to come to a consensus about. If you're looking for a definite answer about which one to choose, I don't think you're going to get anything convincing other than personal preferences of readability vs line count.
Discuss this with the others that maintain your code base and decide on which should be preferred. Clearly explain why. Then move on to more...err...important issues.
As for my preference? I like option 1. To me, it's more readable, the variable name can be something descriptive like isActive, which makes the code easier to read. Also, inspecting values during debugging is probably easier as you have a definite variable with which to reference prior to its use later in the chain. Again, that's my preference.

How to clean and divide your java code? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My project classes are quickly approaching large numbers of lines into the thousands. Is it good programming practice to divide the classes Into smaller classes even if they do the same thing? After all I'd hate to create communication caller functions for the same object.

It is a good programming practice to split up your code so you (and others) don't get lost.
Split it into methods/functions/procedures, classes and packages by meaning, not by size alone.
If several classes do the same thing, have you thought about using inheritance? Don't duplicate code, it makes maintenance harder (and is a waste).
For Java, interfaces and abstract classes can also improve legibility and structure of your code; use with moderation. Many Java IDEs come with handy "refactoring" functionalities which allow you to restructure your code easier and cleaner than copy/paste would be.
( Possibly related topic: "how do you organize your programming work" how do you organize your programming work )

As a rule, each class should have one responsibility that you can clearly state. If you can't state a single purpose for a class, or the narrowest purpose you can define is nebulous and vague, it's time to refactor.
Of course there are exceptions to every rule, and some classes with a lot of utility methods (like String) will be very large. But I generally take a hard look at the purpose of a class when it grows past about 300 lines. (For the second time - I do it the first time before the class grows past 0 lines.)

Should tricky questions exist on the OCPJP exam? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
When I practice to take the OCJP exam, I see that the questions that I'm suppose to practice on are often trick questions which try to fool my into answering wrong. The example is from the Bathes / Sierra book and a typical trick question is:
Now I wonder if you can tell me if the questions on the real exam also often are trick questions like these or if the actual exam has another style, or if this is close to what I should expect?

The given example is not tricky. It simply measures that whether you know the difference between constructors and methods. Constructors and methods might have the same name, it is not a compilation error.
The exam may contain questions like these to trip up the participants. However, you should keep in mind that every question in the exam is just for measuring your ability and knowledge in certain exam objectives. You should ask yourself while reading the question: "What objective might this question be measuring?"

Now I wonder if you can tell me if the questions on the real exam also often are trick questions like these or if the actual exam has another style, or if this is close to what I should expect?
The point of grilling you through such questions is to help you get your defenses up. This is not a trick question like #Juvanis has pointed out, but such questions will help you develop a pattern to identify faults in code. Usually a pattern begins to emerge and your brain starts to analyze the code like so...
Do all the necessary imports exist and are they correct ?
Are non-static variables accessed from a static context ?
Check method return values and return type.
Check autoboxing / unboxing errors.
... and so on
The real exam is easier. However if you prepare with harder questions, the chances of succeeding are better.