Risky to choose a non-standard Java code indentation style?

Does it make a difference if you choose a non-standard indent style?

This is the style I see most often:

import java.io.FileInputStream;
import java.io.FileOutputStream开发者_高级运维;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class Test {
    static public void main(String args[]) throws Exception {
        FileInputStream fin = new FileInputStream("infile.txt");
        FileOutputStream fout = new FileOutputStream("outfile.txt");

        FileChannel inc = fin.getChannel();
        FileChannel outc = fout.getChannel();

        ByteBuffer bb = ByteBuffer.allocateDirect(1024);

        while (true) {
            int ret = inc.read(bb);
            if (ret == -1)
                break;

            bb.flip();
            outc.write(bb);
            bb.clear();
        }
    }
}

But I prefer this style where everything starts on the next line:

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class Test
{
    static public void main(String args[]) throws Exception
    {
        FileInputStream fin = new FileInputStream("infile.txt");
        FileOutputStream fout = new FileOutputStream("outfile.txt");

        FileChannel inc = fin.getChannel();
        FileChannel outc = fout.getChannel();

        ByteBuffer bb = ByteBuffer.allocateDirect(1024);

        while (true)
        {
            int ret = inc.read(bb);
            if (ret == -1)
                break;

            bb.flip();
            outc.write(bb);
            bb.clear();
        }
    }
}

I find this easier to read but will I encounter problems working with others if I use this style?

1. Decide on a single convention on the team (preferably a standard one in case you want to work with others later)
2. Configure your and everybody elses IDE to use that format and that only.
3. Make the reformat happen automatically and preferably at every Ctrl-S.

This will make all sources be uniform at all times, and ensure that changes in the source repository is actual changes and not just reformats at a later time.

For Eclipse this can be done by configuring the formatter (I happen to like the defaults), and save the preferences which can then be loaded by everybody else. Also the Java -> Editor -> Save actions allow for automatic reformatting at every Ctrl-S, which is also a savable preference.

I've found with the above that an additional heuristic

• Everything must fit on a single line

gives a lot of automatically triggered refactorings giving a lot of named locals which then capture intent by their naming, which in turn works well for debugging as you generally have more values in variables which show up in the debugger when single stepping, and you tend to have less opportunities for NullPointerExceptions on each line.

Edit: I wrote on my blog about this.

Edit 2014-08-19: It appears that if the Eclipse formatter settings are saved to a file, IntelliJ IDEA can format source using that file.

Stick with conventions. You should be looking at code outside of your immediate project, programmers move, companies are acquired, tools will tend to be configured for the standard, etc.

It doesn't matter which style you use, but make sure it's consistent with the rest of your team.

Usually this involves endless discussions but I guess that the 2 ones listed here are the more common ones.

It doesn't matter. Most companies use a code formatter anyways.

I also prefer the second style.

You will not have problems with others if they all use the same brace placement and indentation standard as you do.

You will have problems if you're a lone wolf.

The biggest issue will be with your version control system. You don't want people to "oil can" between styles and have lots of differences showing up because of style changes rather than substantive code modifications.

When in Rome, do as the Romans do. Come to a consensus in your team and stick with it.

PS - I'm with you: I prefer to have braces on the next line. The Sun convention is the first one. It's better for book authors, because there's less white space.

As ever when it comes to code formatting, it is risky if you work with someone who prefer the other one.

I stopped worrying about code formatting long ago. What a waste of oxygen, to argue about placement of curly braces. When I have to modify code, I reformat the file with the IDE's code formatter, using the defaults. Then I do my work and commit it. When someone else changes the file, they can format it to their liking. I could not care less.

I'd sooner programmers spent their time discussing algorithms, data structures, and test strategies.

It's all a matter of choice really. If you find a method easier to read than the other than go ahead!

The only exception to this is when you are working on and contributing to a large scale project. In this scenario you will obviously have to follow the convention which is maintained throughout the rest of the source code.

I'm personally a fan on the first way and the majority of people follow this convention.

This is more a religeous question, than a programming question. People have strong opinions about code formatting style. The first format does follow the style that Sun Microsystems has promoted, the second format follows what I like to call not-monkey style. As mentioned above, strong opinions abound concerning code formatting style.

As stated by one or more previous posters, companys use code formatters, so your preferred format style may not survive a checkin to source control.

Consistancy is important, but in a team of 6 programmers, if 5 goof rockets produce hard to read code, it may be a good idea to be inconsistant with them and, attempt, to produce not-hard to read code.

Consistency is all important.

If you like the second style, stick with it. ( I do.)

BUT whatever style you eventually choose to use, do not change it in the middle of your code.

{edit] Netbeans has an option to display the code in your style of choice, IIRC.

I disagree with your title. How is the 1st one standard and the 2nd one non-standard?

Preferences changes over time. We no longer program on 80*25 text terminals. We are writing different type of codes. The justification to save one line becomes more and more amusing.

@RequestMapping(value="/hotels/{hotel}/bookings/{booking}",
                method=RequestMethod.GET)
public String getBooking(
        @PathVariable("hotel") long hotelId, 
        @PathVariable("booking") long bookingId, 
        Model model) {                                    // WOW! I SAVED A LINE!
    Hotel hotel = hotelService.getHotel(hotelId);
    Booking booking = hotel.getBooking(bookingId);
    model.addAttribute("booking", booking);
    return "booking";
}

The answer is that it depends on the audience for the code. If only you will ever see the code, then you may do what you like. If others may see the code, then it depends on your social and/or professional relationship with them. If others might modify the code, then it would be unprofessional not to attempt to code in some standard way.

Adopting the standard style as laid down by Sun over a decade ago will make it easier for people new to your organisation to get up to speed, it'll be code formatted in a way they've been used to during their prior careers.

Apart from that, any (well thought out) style will do as long as it is applied consistently (I've had a hall of a time figuring out inconsistently styled code, where different people working on it had employed different styles even while modifying existing methods).