Local variables should be contained within the smallest scope possible.
The most optimal solution is therefore to create the local variable the same place as it is used. Thereby increasing the readability of the code and minimizing the chance of misusing the variable.
Whenever given some sort of iterable list of data, it should be considered whether if it possible to handle it as a collection or an array, since these types can utilize for-each loops.
For-each loops are from a readability perspective the most optimal way of iterating through the data.
Compared with Iterator or for loop, the for-each loop does not require the developer to be aware of the limit of elements. Thereby decreasing the chance of errors.
Lots of developer experts have over time contributed with great utility libraries. These libraries should be utilized whenever needed, instead of developing your own solutions.
Stand on the shoulders of other developers and contribute with new unique concepts instead.
If working with a domain which require precision, such as currency, it is not ideal to use float or double primitives to store.
Both primitive types include decimals after the comma, but these decimals are actually calculated estimates, which will on a large enough scale start to vary from the true value.
Instead use integers and simulate the decimals after the comma.
Primitive types and boxed types differ on three point:
Because of the reasons mentioned above, always use primitive types over boxed types.
Strings are a convenient format, which can be used to store both textual, numeric, aggregated, and many other formats.
However, whenever you are in a position of handling anything else then a text message, it will likely be worth utilizing type specific enums, classes or primitive types.
The String-class is immutable, since means that every time the concatenate operation (+) is used between two Strings, it actually creates a new String object and leaves the two previous once in the memory.
This operation can therefore be costly on the performance, when used in correlation with e.g. loops.
In these situations, it is preferable to use the StringBuilder.
Whenever working with an object, which implements an appropriate interface, it is preferable to refer to the object by the interface type, instead of the implementation type.
This will enable much more flexibility in your system, and provide future compatibility with new objects, which implements the same interface.
When working with reflection of concrete objects, it will make your code more fragile and unpredictable, due to the compilers limited insight into the reflected object.
However, by finding and casting the reflected object into its interface or superclass, it will ease the use of working with it.
Nevertheless, it should be mentioned that reflecting objects, can and should now a days be avoided in most cases.
Native methods are a way for java to access platform specific utilities written in C and C++. At some point native methods might have been useful, but with the maturity of java and third-party libraries, it is rarely necessary for a developer to implement their own native methods.
Additionally, native methods are a dangerous area to enter, as there is no immunity for memory corruption.
Optimization is a dangerous thing to enforce on a functional program. Large and risky changes may only produce minimal performance optimization. It is therefore always recommended to consider whether it is worth making these improvements.
Rule 1. Don’t do it.
Rule 2. (for experts only) Don’t do it yet – that is, not until you have a perfectly clear and optimized solution.
In general, most class members in java are following a common set of naming conventions. e.g. constants are written in all upper-case letters, class names always start with a upper case letter, fields and local variables on the other don’t, etc.
Learning and obeying these rules will improve readability and convey intentions much faster and better than starting personal naming conventions.
My name is Daniel H. Jacobsen and I’m a dedicated and highly motivated software developer with a masters engineering degree within the field of ICT.
I have through many years of constantly learning and adapting to new challenges, gained a well-rounded understanding of what it takes to stay up to date with new technologies, tools and utilities.
The purpose of this blog is to share both my learnings and knowledge with other likeminded developers as well as illustrating how these topics can be taught in a different and alternative manner.
If you like the idea of that, I would encourage you to sign up for the newsletter.
Cheers! 🍺
INTEGU uses cookies to personalize your experience and provide traceability for affiliate links. By using the website, you agree to these terms and conditions. To learn more see the privacy policy page.