What about style things covered by Effective Java? These are pretty much all good ideas.
Also, how about some guidelines on concurrency? I'd recommend not using the old concurrency stuff and instead using java.util.concurrent.* for more effective concurrency. This doesn't include the Thread vs Runnable thing, so that's still debatable. On 28 April 2014 08:46, Gary Gregory <garydgreg...@gmail.com> wrote: > Perhaps if one breaks the build, it should be polite to revert that last > commit... > > Gary > > > On Mon, Apr 28, 2014 at 3:07 AM, Ralph Goers > <ralph.go...@dslextreme.com>wrote: > >> I think we need to develop and post some development “guidelines”, “best >> practices” or whatever you want to call it for Log4j 2. Here are some of >> the things I would definitely want on it. >> >> 1. Error on the side of caution. If you don’t understand it, don’t touch >> it and ask on the list. If you think you understand it read it again or ask >> until you are sure you do. Nobody will blame you for asking questions. >> 2. Don’t break the build - if there is the slightest chance the change >> you are making could cause unit test failures, run all unit tests. Better >> yet, get in the habit of always running the unit tests before doing the >> commit. >> 3. If the build breaks and you have made recent changes then assume you >> broke it and try to fix it. Although it might not have been something you >> did it will make others feel a lot better than having to fix the mistake >> for you. Everyone makes mistakes. Taking responsibility for them is a good >> thing. >> 4. Don’t change things to match your personal preference - the project >> has style guidelines that are validated with checkstyle, PMD, and other >> tools. If you aren’t fixing a bug, fixing a problem identified by the >> tools, or fixing something specifically called out in these guidelines then >> start a discussion to see if the change is something the project wants >> before starting to work on it. We try to discuss things first and then >> implement the consensus reached in the discussion. >> >> Of course, the actual coding conventions we follow should also be spelled >> out, such as indentation, braces style, import ordering and where to use >> the final keyword. >> >> Ralph >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker <boa...@gmail.com>
