What's your style

[madknight3]

As I said before, heavily nested state-based functions end up looking like bracketfest, sitting there meaninglessly.

 

Regardless of style, if you end up with something like this it sounds like you need to refactor.

[vm'N]

Don't care as long as you are been consistent with it. There is nothing worse, seen mixed versions in someones code.

if (condition){	// Code}else if (condition){	// Code} else { 	/* Code */ }

[Nuluvius]

Regardless of style, if you end up with something like this it sounds like you need to refactor.

Completely and totally 'took the words right out of my mouth'!

[omniomi]

public function whatever() {    /*      * whatever      * whatever     */    $whatever = whatever; /* whatever */    $whatever = whatever; /* whatever */    if (whatever) {        whatever    } else {        whatever    }}

@media(max-width:whatever) {    .whatever {        whatever: whatever;    }    div.whatever,    div.whatever,    div.whatever {        whatever: whatever;    }}

Opening brackets on their own line and yet another level of indentation within looks messy to me... but I have no strong opinions on the matter; If I am working on someone else's code I will follow their style.

[LePawel]

Regardless of style, if you end up with something like this it sounds like you need to refactor.

Not always possible unless you pass unusually large amounts of variables and inventive naming

[Nuluvius]

Not always possible unless you pass unusually large amounts of variables and inventive naming

 

I think that you are completely missing the point. You shouldn't ever be in a situation where you are doing this kind of thing. If you are then you are almost certainly doing something wrong architecturally and you need to look at your design. It's something that is known as a code smell.

[LePawel]

I think that you are completely missing the point. You shouldn't ever be in a situation where you are doing this kind of thing. If you are then you are almost certainly doing something wrong architecturally and you need to look at your design. It's something that is known as a code smell.

You certainly have a point here, and I see how this is true in most cases. Lets make it simpler then, what about large if-else set used for e.g. text file loading or a switch to handle user input with 20+ key bindings? 

You could try categorizing them, but it sometimes could end up with meaningless function names that don't help readability in any way.

[Nuluvius]

You certainly have a point here, and I see how this is true in most cases. Lets make it simpler then, what about large if-else set used for e.g. text file loading or a switch to handle user input with 20+ key bindings? 

You could try categorizing them, but it sometimes could end up with meaningless function names that don't help readability in any way.

 

It's still far too convoluted, manual and difficult to maintain - in short that's spaghetti code. I do understand how and why it arises though, we have all been there and done that.

 

Now lets address your examples; ask yourself: in the most quintessential sense what is it that I'm trying to achieve? try to think about the concerns you have to deal with, try to observe any patterns that might already exist or evolve. Assuming that we are dealing with OO and not a functional/procedural paradigm (they have their own design patterns and methodologies) you want to be thinking about OO design patterns and polymorphism here.

 

For the text example you can probably quite easily break things up into classes. For the large switch/if else statements (incidentally that's another code smell) then perhaps a factory pattern might be applicable? Look for commonality in the input commands and push that up the class inheritance hierarchy. If there's little to none then lambdas might work best... You might find it more maintainable to instantiate a series of lambdas from the factory and store them in a dictionary for instance. Basically the point is that you break the big if else cases out and encapsulate all of that complexity away behind the factory pattern.

 

It's the same idea if you are addressing your primary concern and you start to notice a secondary concept/concern creeping into that code. Stop, extract and encapsulate it, either in a method or some class. The specifics of how you implement the guts of it is up to you, that is known as the implementation detail - it shouldn't be exposed to the outside world. Think very carefully about each public interface - who's going to care about it? how are they going to interact with it? what does it mean? Coupling kills so aim to have things as loosely coupled as possible.

 

Be mindful of methods that get longer than a quarter of a screen and classes that get longer than a screen - those are both code smells. In your system each method, class, namespace and assembly should ideally be dealing with one single concern only. Following this doctrine you will keep your code short, concise, readable, maintainable, testable and very extensible!

 

You might like to take a look at Test Driven Development (TDD) and Behaviour Driven Development (BDD) as both help greatly with architecture, naming of things and the general evolution of the design. When thinking about testing and the separation of what's behaviour and what's implementation detail the Ports and Adapters Hexagonal architecture can be very helpful. One other thing to think about that should help you when trying to break things up is Dependency Injection.

[LePawel]

-nom-

Thanks, lots of good info. I guess it's a lot of stuff that my uni didn't bother even mentioning. I might look into ways to make my file-loading system map based, and some other ideas I can probably utilize in my projects... It's hard to learn C++ 11 when you were fed 03 for 3 years when learning from scratch.

[SpaceCowboy113]

Style 1: Makes it easier to match brackets

Style 2: Increases the amount of code you can have on your screen at once

 

I was using the first style for a while, but I've recently switched to the second.  The first style can add a lot of fluff to your code.

[Nuluvius]

Thanks, lots of good info. I guess it's a lot of stuff that my uni didn't bother even mentioning. I might look into ways to make my file-loading system map based, and some other ideas I can probably utilize in my projects... It's hard to learn C++ 11 when you were fed 03 for 3 years when learning from scratch.

 

No problem it must be frustrating indeed. There's quite a lot of people who end up on here asking for help with their school/uni assignments often in VB and WinForms, sometimes they are using C++ and aren't even aware of the newer features.

 

It's all usually the same ancient monolithic curriculum flopping around in various unsurprising, laborious permutations; clung to by lecturers unable/too afraid to embrace change... A very sad culture indeed. It does little to help when beginning in the industry... As a result one goes in equipped with obsolete tools and knowledge despite paying extortionate tuition fees in some cases.

[LePawel]

No problem it must be frustrating indeed. There's quite a lot of people who end up on here asking for help with their school/uni assignments often in VB and WinForms, sometimes they are using C++ and aren't even aware of the newer features.

 

It's all usually the same ancient monolithic curriculum flopping around in various unsurprising, laborious permutations; clung to by lecturers unable/too afraid to embrace change... A very sad culture indeed. It does little to help when beginning in the industry... As a result one goes in equipped with obsolete tools and knowledge despite paying extortionate tuition fees in some cases.

Yeah, considering I'm getting my degree in 2 weeks, I'll have to make a list of stuff to learn in free time

[ICantThinkOfAnyGoodName]

I use the second one, because it looks much cleaner IMO and because it uses less space.

[Makerimages]

Op type 2 for me, with a space between the ) and {. I feel this is much cleaner, and the file is easier to scroll-search, too.

[YellowDragon]

In an ideal world there should be very little need for documentation/comments in the code at all.

Im a lazy programmer, I comment even minor things, the idea is that I dont want to try to figure out how it works if I have left notes on what does what. 

 

I still try to make my code as good as possible but I add a ton of comments as anyone else that might try to use any part of the project I want them to fully understand whats going on and that means making them understand with as little effort as possible on their end as it removes the chance they will partially understand the solution and implement a sub-optimal code structure.

 

TLDR : If it took a Rocket Rockstar Computer Scientist to write then I want Joe the average scripter to be able to maintain a system without screwing it up.

[Nuluvius]

Im a lazy programmer, I comment even minor things, the idea is that I dont want to try to figure out how it works if I have left notes on what does what. 

 

I still try to make my code as good as possible but I add a ton of comments as anyone else that might try to use any part of the project I want them to fully understand whats going on and that means making them understand with as little effort as possible on their end as it removes the chance they will partially understand the solution and implement a sub-optimal code structure.

 

TLDR : If it took a Rocket Rockstar Computer Scientist to write then I want Joe the average scripter to be able to maintain a system without screwing it up.

 

I'm not inclined to agree with you when you talk about 'commenting even minor things'. Commenting every facet of the language is simply bad form. I'd hope that anyone reading the code were at least familiar enough with the language to understand what was going on. Thickly commented code usually stinks of a bad design or simply badly written code... I know that every time I encounter a thicket of comments I usually start feeling some anxiety blossoming.

 

In a well designed and tested system adhering to good principles, classes should be no longer than a screen length, methods no longer than 1/4 of a screen and each of them should be doing only one single thing. The code should be short and concise and the names of things should be good enough to tell the reader what exactly is going on.

 

Don't misunderstand me however, I am not an anti comment evangelist. I believe, like with all tools, that there's an appropriate time and place to use them. For instance in areas where you are not sure, need to make an assumption, use obscure optimizations - just a few examples...

[YellowDragon]

I'm not inclined to agree with you when you talk about 'commenting even minor things'. Commenting every facet of the language is simply bad form. I'd hope that anyone reading the code were at least familiar enough with the language to understand what was going on. Thickly commented code usually stinks of a bad design or simply badly written code... I know that every time I encounter a thicket of comments I usually start feeling some anxiety blossoming.

 

In a well designed and tested system adhering to good principles, classes should be no longer than a screen length, methods no longer than 1/4 of a screen and each of them should be doing only one single thing. The code should be short and concise and the names of things should be good enough to tell the reader what exactly is going on.

 

Don't misunderstand me however, I am not an anti comment evangelist. I believe, like with all tools, that there's an appropriate time and place to use them. For instance in areas where you are not sure, need to make an assumption, use obscure optimizations - just a few examples...

 

I comment heavily because I have to depend on external resources that I have no idea how they work or what bugs they might have (large company), aka call a resource request from a particular service and parse that data in a particular way.

 

One other think the company I work for hires a few internal programmers, alot of work gets contracted out for cheaper....so you honestly have no idea what random contractor of questionable programming knowledge you will get ( in which if someone is confused, guess who has to do that work then, so I have a high incentive to write clean code with comments that may be redundant but at least someone can pull crap like blah blah uncommented code to some manager that does not know any better to cover their own ass).

 

Good practice and good form is nice ( alot of my side projects), however as soon as your code has to be read by other people even the best design practices and structure needs comments. To be honest if I see green lines my eyeballs will ignore it unless im having problems with figuring out what code does...............

Don't even get me started when you have to work with in house architecture as well.......at that point you would wish someone would comment (many do not)

 

Quick mockup:

// This method is used in order to write data from xxx proprietary database 1 and 5.//See Internal System document XXX for more detail on integration located in the databases section Rev 2.4.1 (3/11/2013) public void WriteFile(string FilePath, byte[] Data)        {            //grab the name of the target file            int startFileName = FilePath.LastIndexOf("\\");            //where do we want to write?            string outFile = ExportFolder + FilePath.Substring(startFileName, FilePath.LastIndexOf(".") - startFileName) + FileExtension;            //declare new filestream and write byte data to filestream            using (FileStream outFs = new FileStream(outFile, FileMode.Create))            {                outFs.Write(Data, 0, Data.Length);            }        }

 I have a PDF containing complete breakdowns that include software class diagrams and architecture views, I make sure that any system I write stays working and can be maintained with the infinite money theorem cause that's what will maintain it after I done with the first roll out.

 

In short though all code is bad

(read this if you haven't yet: http://www.stilldrinking.org/programming-sucks

[Nuluvius]

-snip-

 

In that case I can agree and sympathise. It's a hostile development environment and you are doing the best you can which is a shame. Ultimately depending on so much external resource is a terrible way to develop software. The skills and expertise doesn't stay in house, there are language barriers and as you rightly put it - you just don't know what ability you'll get and how much they will care about doing a good job. There's far to many duct tape programmers out there for my liking.

 

That link is broken btw.

[Atmos]

And I don't understand people who pile stuff into the smallest possible space at the cost of readability to 'save 15-20 pointless lines' in their opinion.

Because there's an art form in compacting, and making more efficient code. That is after all, what hacking started out as.

[Nuluvius]

Because there's an art form in compacting, and making more efficient code.

 

Sorry but compacting code has absolutely no relation to it's efficiency... If you had been reading the flow of contention in this topic it does have an impact upon readability (from the context of an individual).

 

As for it being an art from, yes I will agree with you on finding syntax aesthetically pleasing - when it is properly formed that is - again individual opinion will differ as to what that means.

 

That is after all, what hacking started out as.

 

I highly doubt it.

[SSL]

I'm not inclined to agree with you when you talk about 'commenting even minor things'. Commenting every facet of the language is simply bad form. I'd hope that anyone reading the code were at least familiar enough with the language to understand what was going on. Thickly commented code usually stinks of a bad design or simply badly written code... I know that every time I encounter a thicket of comments I usually start feeling some anxiety blossoming.

 

In a well designed and tested system adhering to good principles, classes should be no longer than a screen length, methods no longer than 1/4 of a screen and each of them should be doing only one single thing. The code should be short and concise and the names of things should be good enough to tell the reader what exactly is going on.

 

Don't misunderstand me however, I am not an anti comment evangelist. I believe, like with all tools, that there's an appropriate time and place to use them. For instance in areas where you are not sure, need to make an assumption, use obscure optimizations - just a few examples...

 

Self-documenting code. What a concept.

[bobdabiulder]

#2.  I like it better!