Are you good at Maths?

[Irwell]

That's silly, this is the exact reason why comments and decent code exists. Naming variables in a clunky and overly long manner doesn't solve anything. Any programmer worth his salt should fully understand what is going on using i and j just by looking at the Wall.RemoveBrick call. i will represent the column and j represents the row. It's perfectly intuitive because that's how 2D arrays work.

So, given a scenario where you have a particularly complex function performing a number of calculations within a series of loops would you:

a) create a lot of extra functions to subdivide to functionality to make it easier to read
b) reuse your i,j,k variables and leave it to the reader to work out where one loop has ended and the next has started
c) give a small amount of detail in the variable name to allow the reader to work out what the variable contains without having to work out where in the code it appears first

The common method is c), for obvious reasons. Nobody wants a load of extra functions or to have to spend time working out which version of i they are dealing with.

Anybody building the RemoveBrick method with the prototype of (i, j) will automatically use it in the same way. Why would anybody in their right mind reverse the perfectly understood and well established precedent?

Agreed, x,y parameters probably weren't the best example. Maybe if it was intAge and intGrumpiness instead? If I was trying to create grumpy cats of all possible age and grumpiness combinations would the code GrumpyCats.CreateNew(i,j) be easy to read or would GrumpyCats.CreateNew(intAge,intGrumpiness) be easier? Would GrumpyCats.CreateNew(j,i) be incorrect? I don't know, I'd have to scroll somewhere else or look in some documentation to see what i and j were.

More to the point, for the time it took to write intCurrentWallRow and intCurrentWallCol, I could have written

// i=col, j=row

for the exact same benefit.

Autocomplete fixes the typing issue. Regardless of how good you are at subdividing your code, sometimes you end up with functions that are hundreds of lines with multiple loops. The last thing I want to be doing when I'm debugging some code at line 219 is scrolling up to line 27 to see what variable i was. It should be obvious when reading line 219 what line 219 is supposed to do.

Readable code is not created by naming every single variable as explicitly as possible, there has to be some common sense at some point. Otherwise you end up with CarFactoryFactoryFactory and the like of.

Agreed, and I wouldn't expect it to the nth degree, for example intNewCatGrumpinessAgeValue, just a simple description that fits within the context of the surrounding code would do, for example intAge.

If my project manager asked me to do so, unless the loops were particularly long or complicated, I'd laugh. It's the height of "too much time on my hands"

We have scripts that document the code automatically. So do most places these days. If naming conventions aren't followed then that bit of code needs to be manually documented, so not following the convention has to be the exception rather than the rule. Also, developers have a habit of nesting things and doing things in a way that makes sense to them rather than you, I accept that because I do it myself. The problem is, if you don't describe your classes, objects, functions, variables, etc. effectively it gets quite messy trying to see where someone else's logic has gone wrong. It's one of the pitfalls of collaborative development.

 

[Irwell]

Pretty much all of your post here suggests to me that this is a grossly unhealthy software project.

Test and Qualification of the overall solution will be enormously expensive and almost impossible (in my opinion).

Which aspect suggests that to you may I ask? We follow a RAD development model, except for the requirements phases which are handled jointly with the client due to it being a bespoke system. The system is OO, MVC and standards-compliant.

 

[Gaylord du Bois]

That's silly, this is the exact reason why comments and decent code exists. Naming variables in a clunky and overly long manner doesn't solve anything. Any programmer worth his salt should fully understand what is going on using i and j just by looking at the Wall.RemoveBrick call. i will represent the column and j represents the row. It's perfectly intuitive because that's how 2D arrays work.

So, given a scenario where you have a particularly complex function performing a number of calculations within a series of loops would you:

a) create a lot of extra functions to subdivide to functionality to make it easier to read
b) reuse your i,j,k variables and leave it to the reader to work out where one loop has ended and the next has started
c) give a small amount of detail in the variable name to allow the reader to work out what the variable contains without having to work out where in the code it appears first

The common method is c), for obvious reasons. Nobody wants a load of extra functions or to have to spend time working out which version of i they are dealing with.

Anybody building the RemoveBrick method with the prototype of (i, j) will automatically use it in the same way. Why would anybody in their right mind reverse the perfectly understood and well established precedent?

Agreed, x,y parameters probably weren't the best example. Maybe if it was intAge and intGrumpiness instead? If I was trying to create grumpy cats of all possible age and grumpiness combinations would the code GrumpyCats.CreateNew(i,j) be easy to read or would GrumpyCats.CreateNew(intAge,intGrumpiness) be easier? Would GrumpyCats.CreateNew(j,i) be incorrect? I don't know, I'd have to scroll somewhere else or look in some documentation to see what i and j were.

More to the point, for the time it took to write intCurrentWallRow and intCurrentWallCol, I could have written

// i=col, j=row

for the exact same benefit.

Autocomplete fixes the typing issue. Regardless of how good you are at subdividing your code, sometimes you end up with functions that are hundreds of lines with multiple loops. The last thing I want to be doing when I'm debugging some code at line 219 is scrolling up to line 27 to see what variable i was. It should be obvious when reading line 219 what line 219 is supposed to do.

Readable code is not created by naming every single variable as explicitly as possible, there has to be some common sense at some point. Otherwise you end up with CarFactoryFactoryFactory and the like of.

Agreed, and I wouldn't expect it to the nth degree, for example intNewCatGrumpinessAgeValue, just a simple description that fits within the context of the surrounding code would do, for example intAge.

If my project manager asked me to do so, unless the loops were particularly long or complicated, I'd laugh. It's the height of "too much time on my hands"

We have scripts that document the code automatically. So do most places these days. If naming conventions aren't followed then that bit of code needs to be manually documented, so not following the convention has to be the exception rather than the rule. Also, developers have a habit of nesting things and doing things in a way that makes sense to them rather than you, I accept that because I do it myself. The problem is, if you don't describe your classes, objects, functions, variables, etc. effectively it gets quite messy trying to see where someone else's logic has gone wrong. It's one of the pitfalls of collaborative development.

This.

 

[Oohvonkyvonky]

Not really my cup of tea.

 

[Damocles]

So, given a scenario where you have a particularly complex function performing a number of calculations within a series of loops would you:

a) create a lot of extra functions to subdivide to functionality to make it easier to read
b) reuse your i,j,k variables and leave it to the reader to work out where one loop has ended and the next has started
c) give a small amount of detail in the variable name to allow the reader to work out what the variable contains without having to work out where in the code it appears first

Not a fair question really as it depends on the circumstance. I would do whichever would benefit the most. You can make the argument that any function that needs to have a number of complex calcuations in a series of loops is badly designed and needs a rewrite anyway. If I just had to change an index variable name to make it clear, I would obviously do this.

Agreed, x,y parameters probably weren't the best example. Maybe if it was intAge and intGrumpiness instead? If I was trying to create grumpy cats of all possible age and grumpiness combinations would the code GrumpyCats.CreateNew(i,j) be easy to read or would GrumpyCats.CreateNew(intAge,intGrumpiness) be easier? Would GrumpyCats.CreateNew(j,i) be incorrect? I don't know, I'd have to scroll somewhere else or look in some documentation to see what i and j were.

//i = age, j = grumpiness

Autocomplete fixes the typing issue. Regardless of how good you are at subdividing your code, sometimes you end up with functions that are hundreds of lines with multiple loops.

Disagree. If you have some functions that are hundreds of lines with multiple loops, you need to rethink the design of the section. I know it happens on codebases over years as programmers and requirements change but we are arguing a perfect world scenario here.

The last thing I want to be doing when I'm debugging some code at line 219 is scrolling up to line 27 to see what variable i was. It should be obvious when reading line 219 what line 219 is supposed to do.

Agree but here we go back to my earlier point. Also, a combination of a decent debugger and IDE will solve this problem. Right click->Find Definition.

We have scripts that document the code automatically. So do most places these days. If naming conventions aren't followed then that bit of code needs to be manually documented, so not following the convention has to be the exception rather than the rule.

These scripts are literally useless. One of the most basic ideas about commenting is that it should describe what the code is doing and not describe the code itself. Saying

//remove bottle from wall

for(int i=0;i <10;++i)
{
     Wall.RemoveBottle(i);
}

is literally the most useless thing you can say. It is self evidence that a call to RemoveBottle will remove a bottle.

The self producing documentation should only be used as an addition to a decent commenting system, not as a replacement for it.

Also, developers have a habit of nesting things and doing things in a way that makes sense to them rather than you, I accept that because I do it myself. The problem is, if you don't describe your classes, objects, functions, variables, etc. effectively it gets quite messy trying to see where someone else's logic has gone wrong. It's one of the pitfalls of collaborative development.

I agree when we're talking about the naming of classes, objects, functions, and variables which have large scope. But we're talking about variables that have local scope to the loop and disappear after. If you're writing nested loops where it isn't obvious what i and j are doing, it is your method names and commenting you need to work on; naming the index variables is putting a plaster on a broken knee.

 

[pauldominic]

Pretty much all of your post here suggests to me that this is a grossly unhealthy software project.

Test and Qualification of the overall solution will be enormously expensive and almost impossible (in my opinion).

Which aspect suggests that to you may I ask? We follow a RAD development model, except for the requirements phases which are handled jointly with the client due to it being a bespoke system. The system is OO, MVC and standards-compliant.

You appear to be project manager and think of it as yours.

The project is at least 5 years old. This isn't a good sign.

Initially I thought you were also doing the conceptual design as well as being project manager. I hope this isn't the case.

Large scale developments should not be using extremely strict coding standards.

Code does not document itself.

Clients are not the same as Customers and there appears to be no understanding of who the Customer is.

Manual documentation of the Customer Requirements Definition, Requirements Analysis and Project Design is vital and essential.

The overall solution has thousands of classes and millions of lines of code. Also not a good sign.

The debugging phase needs code that is written as English so that it can be debugged without having to dig into the meaning.

The project is a bespoke solution where the design authority lies with the client. This means that all the investment and engineering costs can't be transferred to a manufacturing run and have to be born by the business rather than paying customers.

The developers should be fundamentally involved in translating the business logic into an analysis and design rather than developing the business logic which by now should be almost set in concrete.

The software development lifecycle has 6 subdivisions. I have no idea what you mean here.

The sub-divisions can often be combined but its normally a cost based compromise. Changing the project methodology in the name of cost saving mid project adds extra risk and complexity and rarely saves any money at all. Cost increases are far more likely and common.

 

[Damocles]

The software development lifecycle has 6 subdivisions. I have no idea what you mean here.

I may be mistaken but I think he's talking about the waterfall model

[bigimg]http://www.buzzle.com/img/articleImages/53717-5.jpg[/bigimg]

 

[BimboBob]

The software development lifecycle has 6 subdivisions. I have no idea what you mean here.

I may be mistaken but I think he's talking about the waterfall model

[bigimg]http://www.buzzle.com/img/articleImages/53717-5.jpg[/bigimg]

Where are the hidden rocks?

 

[Hamann Pineapple]

A pizza with the radius of 'z' and thickness of 'a' has the volume pi*z*z*a

 

[Irwell]

Sorry if I've missed any points here, I've tried to pick out your comments from mine.

You appear to be project manager and think of it as yours.

Yes, my pet. It's what you do with projects.

The project is at least 5 years old. This isn't a good sign.

Yes, we handle the whole product lifecycle for the client, from design to decommission.

Initially I thought you were also doing the conceptual design as well as being project manager. I hope this isn't the case.

Several hundred people work on this project in different capacities. There are a number of people with a design authority role for different aspects of the system.

Large scale developments should not be using extremely strict coding standards.

I disagree, it would be impossible to do so without. This isn't just something that is my preference, though I agree with it myself, it's actually something dictated by both my employer and the client. I won't go into the reasons for client input on coding standards, suffice to say there is a reason.

Code does not document itself.

If you are a decent programmer then it does. I wouldn't hire someone whose portfolio indicated they weren't capable of this.

Clients are not the same as Customers and there appears to be no understanding of who the Customer is.

I'm well aware of who the customer is. I won't go into details on this, however, for obvious reasons.

Manual documentation of the Customer Requirements Definition, Requirements Analysis and Project Design is vital and essential.

Yes, I agree it is. We also generally automate the creation basic application structure from the requirements documentation. Code documentation, however, is something that is mostly automatically documented and self-documenting.

The overall solution has thousands of classes and millions of lines of code. Also not a good sign.

It's the nature of the project, one of the largest IT software projects in Europe over the last decade. I won't tell you exactly which number as you'd be able to work out which project it is. The reason for the number of classes and lines of code is the sheer complexity of the functionality.

The project is a bespoke solution where the design authority lies with the client. This means that all the investment and engineering costs can't be transferred to a manufacturing run and have to be born by the business rather than paying customers.

I'm not sure how you work that out. Where design authority lies with the client they obviously take on some of the development risk as any error in the design is theirs.

The developers should be fundamentally involved in translating the business logic into an analysis and design rather than developing the business logic which by now should be almost set in concrete.

The logic is entirely set in concrete. If the logic is wrong then we head back to the requirements stage and the client pays for an alteration to the design. We have architects who are responsible for translating the requirements into a suitable object model. The programmers are then responsible for implementing this object model and the functionality it exposes.

The software development lifecycle has 6 subdivisions. I have no idea what you mean here.

Damocles was right, I meant the waterfall model. That said, we use a hybrid of the waterfall model and RAD.

The sub-divisions can often be combined but its normally a cost based compromise. Changing the project methodology in the name of cost saving mid project adds extra risk and complexity and rarely saves any money at all. Cost increases are far more likely and common.

I've never said we do that though. We have a set methodology which is closest to the waterfall model, but with elements from RAD at the design/development phases. The reason I mentioned that they can be combined as a cost-saving compromise is because of a statement you made about development methodologies.