I have a question about Java style. I’ve been programming Java for years, but primarily for my own purposes, where I didn’t have to worry much about style, but I’ve just not got a job where I have to use it professionally. I’m asking because I’m about to have people really go over my code for the first time and I want to look like I know what I’m doing. Heh.
I’m developing a library that other people will make use of at my work. The way that other code will use my library is essentially to instantiate the main class and maybe call a method or two in that. They won’t have to make use of any of my data structures, or any of the classes I use in the background to get things done. I will probably be the primary person who maintains this library, but other people are going to probably look at the code every once in a while.
So when I wrote this library, I just used the default no modifier access level for most of my fields, and even went so far as to have other classes occasionally read and possibly write from/to those fields directly. Since this is within my package this seemed like an OK way to do things, given that those fields aren’t going to be visible from outside of the package, and it seemed to be unnecessary to make things private and provide getters and setters. No one but me is going to be writing code inside my package, this is closed source, etc.
My question is: is this going to look like bad style to other Java programmers? Should I provide getters and setters even when I know exactly what will be getting and setting my fields and I’m not worried about someone else writing something that will break my code?
I would be very loath to go into a code review with anything but private fields, with the possible exception of a protected field for the benefit of a subclass. It won’t make you look good.
Sure, I think from the vantage point of a Java expert, you can justify the deviation from style, but since this is your first professional job using Java, you aren’t really in that position.
So to answer your question directly: “Is this going to look like bad style?” Yes, it will.
Was your decision reasonable? Only if you are really confident that this code won’t go anywhere. In a typical shop, there may be chances to reuse code, factor things out into utility classes, etc. This code won’t be a candidate without significant changes. Some of those changes can be automated with IDEs, and are basically low risk, but if your library is at the point where it is stable, tested and used in production, encapsulating that later will be regarded as a bigger risk than was needed.