How to write "clean" java code

Discussion in 'Programming' started by Flyin, Jan 6, 2016.

  1. Hello, I have been working on some large java projects lately and have run across one problem again and again. This problem is creating "beautiful" code. I am very much of a protectionist so when I create code that I know could be better, it bothers me. Is there any information, links, wikis, etc that anyone can give that would help me produce code that is better looking and Easter to understand.

    Any help would be much appreciated!
    Thanks Flyin.
  2. There are alot of different styles, and saying "this is how your code should look" isn't really possible. Take a try at different styles and see which ones you feel looks the best and work the best for you.

    What ever you do, however, keep it consistent.
  3. Even though there is no "official" style, is there one in particular that is looked up to? I am fairly new to making large projects so I want to start off at a good point to avoid having to fix problems later on.

    Thanks for the reply,
  4. If you're interested, this video is not bad either.
    I know that it's php related but he explains some stuff regarding code indentation.

    Maybe it helped you out :)
    • Informative Informative x 1
  5. Thanks m8
  6. You're probably not the only one who has this question... but here's some of my 'insights'
    • Programming Style Make sure it's consistent i.e. Stick to just one style, it helps reading the code later. This also means try keeping the code structure the same through out, indent appropriately and comment your code as needed.
    • Modularity Separate your functions/methods into smaller ones where possible so you can re-use them later on in the code instead of rewriting the function with a new line or two of the code. It'll show more understanding of the language and provide you with more modular, readable code.
    • Logic Make sure it's easy to follow, the above points will help you achieve this, but naming conventions etc etc.
    Generally speaking, before you jump into coding, you should make some sort of plan, think what you'll need, where etc and program following the code. When (for example) I do my university projects, I would use UML tools to draw my classes and different diagrams and follow them accordingly, this reduces the chances of your project failing or looking like a mess at the end, since you know what's needed.
    It'll also allow you to structure your code, modularity wise.
    The last thing is, experience. As time goes by, you'll learn more and more ways of doing things better.
    • Informative Informative x 1
  7. Removed, people have no sense of humor.
    #7 connection_lost, Jan 6, 2016
    Last edited: Jan 6, 2016
    • Funny Funny x 3
  8. What's wrong with that? Elaborate. I see both ways to be perfectly fine and it's a matter of personal preference as to which one someone would use.
  9. What makes you think you can impose him a code style?
    Some people prefer the second one, and it's completely their choice.
    There's no 'wrong' style of the 2 you mentioned...
    • Agree Agree x 2
  10. I did some research, both ways are correct.

    Does anyone have a website that I could reference too for some good practices?
    #10 Flyin, Jan 6, 2016
    Last edited: Jan 6, 2016
  11. @Flyin If you are working in a team you could agree on a common style guide, like this one.
    But of course you can also set your own "standards" and requirements for your code.
    • Like Like x 1
    • Agree Agree x 1
  12. 1. Type code
    2. Get bucket of water
    3. Add Cillit Bang Code Cleaner
    4. Wash Code
    5. Result!!!
    • Funny Funny x 5
    • Like Like x 1
  13. Thanks m8, this is on the line of what I was looking for +1

    Hmm.. Is this an application or a joke?.. xD
    • Like Like x 1
    • Agree Agree x 1
  14. This
  15. A good test to see if you write "beautiful code" get other people who may not be as good as you to read it and see if they can understand it without much issue.

    Sure, it's really nice to do complex bullshit like create an enum in which every item is an anonymous inner class (never do this) however that takes me mental effort in order to properly understand what on earth it is you are trying to do.

    If you want to write really, really good code, live by a few principles:

    • Particularly this one, the DRY principle:'t_repeat_yourself
      If you are writing code that repeats itself in anyway you need to stop, identify the critical piece and break it into a method or loop or something that will allow for you to avoid the repetition.
    • Typically, the less lines of code there are the less mistakes there are. This is something that seems quite stupid, but it is one of the foundational reasons people choose paradigms like functional programming, it allows you to be very clearly expressive. The real point here is write expressive code that does the thing that you want it to. Clean up your code by using setup methods.
    • If something should be an object, make it a freaking object. Don't nilly around with a bunch of related variables, objects are meant to make that problem easier, so USE them.
    • Conform to the style that the codebase you are contributing to uses, and if you are writing a personal project, conform to that particular language's style. This means:
      • Don't use semi-colons in python
      • Use camelcase in java
      • Write OOP code in java
      • Be consistent
    • It is often indicative of a shitty or new programmer when you bull on ahead instead of taking a step back every so often to refactor your code so that it makes sense. Yes, it works, but can anyone else read it without spending a couple of years running it through deciphers?
    • Avoid "Yo-Yo" code.
    • Avoid coupling your code very tightly, and this is a big one. Make as much of your code re-usable as possible. That means spending the time to write that object, that means ensuring that someone can use your FileObject in a project other than the one on your desktop.
    • Remove unused imports, dead code (commented out code that you are keeping "just in case"), overtly verbose documentation. Yes, you heard me, too much documentation is a bad thing.
    • Use version control and for the love of God write your commit messages on a basis of why not what.

    These are things that you will really only be able to implement over time, so pick one and use it. If you want some real world exposure, look at projects on github that are written in the language that you are working in. Try submitting some pull requests to them, they'll correct what you have wrong or outright decline your request if it's totally wrong. This literally shoves you in the correct direction.
    • Winner Winner x 7
    • Like Like x 2
    • Agree Agree x 1
  16. Thanks so much man, I really appreciate it :D

    I wish xD
  17. No, but there's this pretty cool star trophy we can