If you're writing code in a programming language derived from C (i.e. one of those with pesky curly braces), where do you like putting your braces?

Some people like putting the opening brace on a line by itself right after the declaration/statement:

I'm one of those that usually does this. It just was something I got used to from my C/C++ days and since it was the common convention in .NET back when I started fiddling around with it in 2000/2001. So this is usually what I use when coding on C#.

However, other people like to put the opening brace inline with the declaration/statement:

This question is brought to you courtesy of me noticing that IronRuby favors the "inline opening brace" style.

Actually, I use the inline-opening-brace style myself when I'm working with Java. I don't mind it, but it somehow seems wrong sometimes. I mean, using different styles when working across two languages so similar? I mean, I already have enough trouble remembering stuff like string vs. String and ToLower() vs toLowerCase() to worry about how the code looks .

Historical Note: A few years back I used to be weirder and used a mixed style where I used braces-on-next-line for some things and inline-opening-brace for others depending on what it was and how many lines were in between the opening and closing braces. Yes, I was (am?) anal like that. I finally gave up on it when I grew tired of fighting the auto-formatting rules in IDEs.

What style do you favor, and why?

Code Style

As I mentioned a couple of weeks ago, I've been doing some Java work here and there. I don't mind it, and I even welcome the chance to get reacquainted with Java every now and then. For now, the tooling I'm using is a mixture of Vim, the command line, and Eclipse. It works OK, but it hasn't been a fully pleasant experience.

First I ran into a bit of trouble getting the Eclipse debugger to work with Tomcat and getting the project system setup just right. Turned out I was using the wrong project type (!) and once I fixed that I was able to work much better. The Eclipse debugger still sucks, particularly if you've been spoiled by the VS debugger, which, even with it's faults and limitations, is still very good and extremely usable compared to some other tools.

The "feature" that I have come to rather dislike about Eclipse, however, is Perspectives. I don't mind the core idea; it makes total sense: Have a way to configure different settings and options in the environment (particularly around window & UI layout and available options) based on a given context.

However, I find that the way Eclipse implements Perspectives gets in the way I work, for a few reasons. The first one is that there are just too many perspectives, some of which don't quite make sense to me. For example, I see very little reason to have completely different perspectives for Java and Java EE; they share to much in common. Also, the choice of which perspectives are easily accessible (that is, through the Window -> Open Perspective menu option) seems pretty arbitrary and doesn't always work out well (not too mention the fact that the contents of said menu depend on what the current perspective is, which doesn't help).

What I found more annoying about perspectives, though, is that switching between perspectives is a manual process most of the time, which seriously reduces their usefulness, as you have to constantly go through the UI to change the perspective back and forth. For example, Visual Studio also has something similar to perspectives, in the sense that the UI can be customized for certain contexts (such as when coding and when debugging), but the fact that those contexts exists is mostly transparent to the user: Visual Studio will switch between them automatically based on actions you make in the UI, such as starting the debugger. Not so with Eclipse. For example, the Debug perspective doesn't [always] activate automatically when you start the debugger, which I've found pretty annoying.

On the other hand, it's possible I'm just using it wrong

Eclipse

I've been doing some work this week working on SQL Server 2005 Reporting Services using MDX to query OLAP Cubes. It's the first time I had a serious project (that is, do anything significant) using MDX, and it's been an interesting experience.

After a while, MDX starts to sort of make sense, but I will say that, as far as query languages works, MDX has a pretty strange syntax; it's not very readable [1] and I found it pretty absurd that the facilities in the language to work with parameterized queries were so convoluted!

[1] It's probably more accurate to say that queries can be written in a very readable fashion, which is usually useless because it means using a structure that makes it very hard to introduce query parameters. Silly, if you ask me...

MDX, OLAP

Ayende picked up on Jeremy Miller's latest post and commented on the whole idea of "trusting the developers in your team". I think it's safe to say that Ayende is right on the money: If you can't trust them, and you don't want to coach them and help them become better developers, what's the purpose? Why have you hired them in the first place?

However, it's not just a trust issue. I think I've said it in the past; but this issue it's also one of business and understanding of the world of software development. I've voiced my concerns to this line of thinking to people before around here, and one counterclaim I've seen brought up time and time and again by project managers and even owners of IT shops here is that they need the untrained, less skilled, less trusted developer.

It's not that they don't trust them; it's that they hire them to be untrusted and kept with low-skills because some tasks don't require "special" skills. Invariably, I hear stuff like "why would you hire a top-notch developer to create the web UI of the application?" Well.... in my experience, that's usually one of the places that a) is the most visible part of the application, b) is one that can take a lot of time during development, c) is easy to get wrong and others. Besides, this is definitely along the lines of the Mort issues discussed a while ago.

Software Development

Some things I've noticed while using Visual Studio 2008 using the downloadable VSTS VPC image:

• The IDE, in general, seems a bit snappier than what VS2005 is for me. This is good news, and I do hope it keeps this way.
• Contrary to what I expected, the Workflow designer is not snappier. It feels significantly more slow than in VS2005. This is bad news, considering it isn't snappy by any means in 2005
• Can somebody, please, put the stupid Task window out of its misery and stop bugging us with it? It used to pop up at inconvenient times in VS2005, still, but it keeps popping up all the time in Orcas. Extremely annoying.

Visual Studio