As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm currently in the process of cleaning up a a large Java code base, and I was wondering what was the proper (standard?) structure/ordering of a Java class.
What I mean is:
Should public static final fields be first among the fields of a Class?
Where should a static initializer be?
Where should private static helper methods be?
Also, as a side question: is it a good idea to have large harcoded SQL queries for PrepareStatements in the code?
You should be more worried about naming convention, clear code documentation and overall the correctness of the program (i.e. no bugs), after this you can worry about the order of defining variables, methods etc
This is the code convention for Java
To answer (some) of your points:
static initializer usually appears in the begining of your classes, after the variables if it happen to come first.
private methods can go to the end of your class (before variables if they are at the end), but it is matter of preference, because usually the one who reads the code care more about the public methods that the class expose to the rest of the program
Having the SQL statement inside the program or stored externally (e.g. properties file) depends on how often they are changing; but as long as you are using PreparedStatement you should be OK.
Well, here you're gonna find Java code conventions: Java Code Conventions
I really don't like harcoded SQL statements. But, sometimes they are necessary. See if you can encapsulate that on a library (like hibernate or something), or if at least you can break it into minor sql codes.
Adding
I would also take a look at: How to Write Doc Comments for the Javadoc Tool to mantain your code well documented.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have always gone with the popular convention of using access modifiers and encapsulation in order to make sure a class wouldn't break if it was implemented wrong. However, I have noticed that OOP really doesn't need encapsulation and that using access modifiers actually induces more headaches than benefits. Additionally, by not using access modifiers you are being more of an OO programmer. My reasoning is listed below.
Python supports OOP yet it does not use access modifiers or encapsulation. Showing that in OOP languages access modifiers are not mandatory.
Although compilers are more advanced are still nano-second differences between using accessor method versus variable access. In restricted systems like Android this would affect a games FPS drastically. (Although using the final modifier on methods would reduce the nano-second difference significantly in most cases)
By not using private or package modifiers coding gets simpler and faster for the original coder. Future user of the class would still be able to use public interfaces without breaking or playing with the class implementations. Furthermore, if he wishes to modify or upgrade the class he may still do so and access the private modifiers. In an analogy, when you decide to modify a car you know there is a possibility that you may break something, but if you're willing to take the risks and know what you're doing being allowed to open a lock that has a clear sign saying (open at your own risks) is better than having to replace the unbreakable lock, locking the part you wish to modify.
What I do now is a mix of public modifiers for public interfaces and protected modifiers for implementation details so users can do their risk-taking by sub-classing. Is there any reason why I should reconsider doing this instead of conventional encapsulation?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What of the following is used popularly or is the standard :
private List<String> names ;
OR
private List<String> listOfNames ;
OR
private List<String> namesList ;
Once upon a time we had Hungarian notation, because IDEs didn't provide intellisense and programmers were too dumb to realise that having a 30,000 line long block of code was unreadable*. Nowadays IDEs are friendly, programmers have started using small, neat classes, we have JavaDoc and things in genral are easier to read.
So, just name your variable for its usage. i.e. names. I'm no fan of pre/post-fixing variables as it often makes them harder to understand.
(*) i.e. Me, there's probably some deeply shameful code out there with my name on it.
Depends on the use case.
names
If this is the only "names" variable
namesList
If therr are other names collestions (e.g. namesSet) in your code.
private List<String> listOfNames
Is wrong; if you will be so specific you should write listOfStrings or
private List<Name> listOfNames
redefine your type (whatever Name is).
The conventional name will be namesList.
PS : If you use auto complete in Eclipse you'll see that.!
Regarding variable name, you can use anything.
My team says after reading variable name, one should understand what that variable will hold data BUT variable name should be as per Java naming convention.
In your case I would go with listOfNames, because it will say the variable is of type list and it has names.
Also read Java naming convention.
whatever is suitable for you and your team go with that.
IDEs are very smart they will take for everything else like what a given name stands for, type, permissions etc.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Is it bad to use Underscores in Function Names? Can I know the reason why?
ie:
Function GET_NAME(byval sword as string) as string
Not at all. The coding convention is a very subjective term. One might feel one coding style great and another find it worse. The key point is maintain one coding style only throughout your code for ease of upcoming developers and maintainers.
However, avoid all caps for function names (as shown in your example). It's generally reserved for macros (C/C++) / constants.
I would use them sparingly in my own API, but to say that they are bad is simply untrue. If so, .NET specifically would have problems with default naming for event handlers!
void Form_Load( //...
void Page_Load( //...
void btn_Click( //...
// etc.
In this specific case, all caps with underscore separators are generally understood to be constant values.
Firstly, its very subjective matter and depends from Person to Person. One may feel like using _ in function, others may not. There's no harm if you use it.
Frankly speaking, you don't usually use _ sign. But, you can to use this '_' in the variable declaration.
Note : You can check out the msdn link ( atleast for C#,
Visual Basic, C++ )
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm reading some books about coding standard in Java.
I always loved beautiful and clean code.
But there are some things that bother me. For example, a method name should start with a lowercase word, and if it has a second word, it should be start with a uppercase character. But the standard for variables is the same thing. I think this is a little confusing.
So I'm asking you guys, what's your coding standard in Java?
Like:
How do you name objects, methods, classes, etc.
If you have more than one object from same class, how do you name the second one?
If you have one object in the argument of a method and you have another object from the same class inside this method, how you do name both of them?
What is the best trade-off for performance/code beauty, a lot of small methods, or some longer methods?
Feel free to say something more. =)
Mostly following the Java code convention.
I try to not make it matter what kind of class an object is. If I for instance have five different strings, the name of each variable should describe what information/content the variable represents, and not that is is a string.
I find it often silly to try coming up with variations of a variable just because it exists both as a method argument and a class variable. I mostly use the same name with this syntax this.theVariable = theVariable
A method should be as short as possible: as few lines as possible, and as few nested levels as possible (i.e. max one if-statement, and not ifs inside ifs etc.)
Robert Martin's Clean Code is highly recommended!
Just to address one specific point, because it's one I commonly see people doing horrific things with:
If you have more than one object from same class, how do you name the second one?
By their purpose, surely. If you have two different objects of the same class, you must be using them for different purposes, so name it after that purpose. I think all of these examples would be pretty self-explanatory to most readers:
public void copyAddresses(Customer source, Customer destination) {
public void sendMessage(Mailbox sender, Mailbox recipient) {
public void changeContactCompany(User contact, Company from, Company to) {
public void eatWatermelon(Bowl servingBowl, Bowl bowlForSeedSpitting) {
or whatever... you get the idea.
You should start with the official Java Code Conventions.
They will explain why code conventions are needed, different conventions and, what your question seems to be about, naming conventions. They add various examples too.
What is the best trade-off for
performance/code beauty, a lot of
small methods, or some longer methods?
"Premature optimization is the root of all evil" - Donald Knuth
Remember:
Make it work.
Make it right.
Make it fast.
You should only worry about performance if it is warranted; if the current code is too slow to meet requirements.
In that case you should find the 'hot-spots' and optimize those. Check if performance is good enough. If not, repeat.
Well since most of these are easily googled I will add my own standard Java naming practices:
I usually suffix the name of classes of what they extend or implement.
In other words Spring MVC controllers are suffixed with "Controller". This makes it easy in Eclipse to do a Crtl-Shift-R *Controller.
Second if I find I need to aggregate a whole bunch of static methods in a class I usually suffix that class with "Utils". I got this from Apache Commons and has just stuck.
Finally derived methods that do special expensive stuff and are transient I avoid calling them getXXX. The reason is to avoid problems with serializers.
Look here at the official guide
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Why is it convention to place getters and setters after constructors within classes?
I would rather see them placed immediately after class fields, before the constructors, in order to see which of the private fields are accessible via getter & setter methods. Especially if the methods' bodies are single return or assignment statements.
The Java coding convention states that methods (getters and setters are methods) should be after constructors declarations. It just a convention and it exists to make code easier to read in general.
If you judge that the code is more readable with getters//setters after fields rather than after constructor, you're free to do it.
Resources :
Java code conventions - Class and Interface Declarations
Java code conventions - Why Have Code Conventions
My take is that you have fields, then constructors, then methods so you can read through the class saying: "this is what makes up the object, this is how you build it, and having built-it here's what you can do with it".
That said, it's entirely subjective. If another layout makes sense for you and your team in your domain of interest, then do it differently. The only thing you should be wary of is making sure that your projects are internally consistent. It can be very off-putting to see code style change class-by-class.