Java – Advantages and Disadvantages of Forced Code Reformat

"If it's not in source control, it doesn't exist."

This is one of the few things in our profession that I'm borderline dogmatic about. For the following reasons:

1. Even though the workstation is company property, let's face it - there is a bit of an unwritten rule that a programmer's own workstation is his/her castle. I'm just uneasy with a workplace culture where anyone can routinely log onto it and go through it.
2. Everybody has their own flow (as you said as well). Trying to force all developers to organise their own local workspaces a certain way may go against their particular way of working, and break their flow and make them less efficient.
3. Stuff that isn't in source control is half-baked code. If it's fully baked code that's ready for release, it should be in source control. Which comes back again to the main point....
4. "If it's not in source control, it doesn't exist."

One possible way to mitigate the issue of wanting to look at code on people's workstations is to foster a culture of regular checkins. I worked at a company once where - even though there was no official mandate to do so - it was seen a sort of point of pride to always have everything checked in for the weekend. In maintenance and release candidate phases, CR items were deliberately very fine grained to allow for small, cleanly visible changes, and regular checkins to keep track of them.

Also, having everything checked in before you go on vacation was mandatory.

TL;DR version: Rifling through people's workstations is bad form. Rather than trying to foster a culture of making it easy to go through people's workstations to find what we want, it's better practice to foster a culture of sensible source control use and regular checkins. Possibly even hyper-regular checkins, and fine-grained tasks when in critical phases of projects.

I'll give a short answer due to my lack of time at the moment, but I'm currently working on two big projects (> 100.000 LOC in Haskell) - flowbox.io and luna-lang.org. We use Haskell for all the parts, including the backend, compiler of our programming language and even the webGL based GUI. I have to admit that the strong type system and the "dependent type"-like machinery can guide you and save you from burden and hassle known from other languages. We use the types very extensively and everything that could be checked in compile time, is done so. In fact, during the last 3 years of development, we never, ever encountered any runtime error or stack overflow (and this is something really incredible). The only errors are obvious logic errors made by programmers. A lot of people tell, that if something compiles in Haskell, it just works and you should be pretty sure it will not blow in your face some day. This is true for most of the situations and when you know the language well and know what to avoid (like unimplemented typeclass methods), you'll be safe and gain big profits from the type system.

Answering the first part of the question: You can learn about these powerful type system features reading some great blogs, like:

• Bartosz Milewski blog
• Edward Kmett's one
• or Gabriel Gonzales one

In fact, there are a lot of other nice blogs out there (like planet Haskell). Anyway, the best method to really understand the advanced type systems is to develop a useful open source library. We (at Flowbox & New Byte Order) are releasing a lot of libraries (you can find them at Hackage), so if you don't have an idea what to develop, you can always involve into our projects – just email me whenever you want (mail available at luna-lang.org).