0

i just want to ask
how do you prefer your code ?
do you want it to be properly indented ? or maybe with a lot of comments..
anything just describe how you want your code to look like ..

plus numerous lines affect the file size, that's why i'm being cautious as well in using spaces and comments, tho sometimes i just can't help but to use alot

and maybe i could get some good ideas from you guys..
cheers ..

20
Contributors
23
Replies
37
Views
5 Years
Discussion Span
Last Post by <M/>
Featured Replies
  • 1

    It is very important to comment why some code does a particular thing, you can normally tell what it does just from reading the code itself. If you happen to have implement some specific algorithm then I would also comment what algorithm and may be why it was chosen. If … Read More

  • The worst sin is inconsistent indentation. A close second is no indentation at all. Coming in third is indentation of more than about 5 spaces. A close fourth is mixing tabs and spaces. Just use spaces. It needs to line up so people can tell where one bracket starts and … Read More

  • 1

    > how do you prefer your code ? I'm a code aestheticist, so beauty comes a close second to function. Typically I favor transparent code rather than comments because comments tend to make the code uglier unless you do it well. I like consistency (such as indentation and general code … Read More

0

Well dude...
As for me it goes something like this....when I start coding I usually use comments and later clean it up leaving only the things which will indicate what it is and what it does..
amm yeah something like that….

1

It is very important to comment why some code does a particular thing, you can normally tell what it does just from reading the code itself. If you happen to have implement some specific algorithm then I would also comment what algorithm and may be why it was chosen.

If you work in any sort of sized company then comments are extemely important because the next person editing the code may not be you and they will need to know what it going on and why it was done like that.

2

As for me, I never comment, maybe because at my level the complexity is low, and can be understood with little effort. But about the indentation part, i am strict right down the last line. I strictly follow allman style and yes, it will surly help you reduce the number of comment that you might need. And a code with proper indendation is easy to edit later. Cj

0

I agree with you on that Cj, and missing chars or syntax, and the tags can be easily seen. but having too much indention could also be a disadvantage cause i have seen codes like that ..so basically i'm saying this out of my experience ..

4

The worst sin is inconsistent indentation. A close second is no indentation at all. Coming in third is indentation of more than about 5 spaces. A close fourth is mixing tabs and spaces. Just use spaces. It needs to line up so people can tell where one bracket starts and the corresponding bracket ends.

Bad indentation beats out all the other issues you mention. I can handle (sometimes) no comments. Bad indentation is is fatal for me.

Closely related to comments is variable and function naming. Name your variables and functions right and you don't need comments. For example...

double x = z * pow(1 + y, 12); // needs comments



double endingBalance = startingBalance * pow(1 + monthlyInterestRate, 12); // no comments required due to good variable naming.

Some comments are so obvious as to detract, not add to understanding

i++; // increment i (do we really need this comnment?)

Rule of thumb. When in doubt, add a comment. If it's obvious, people just won't read it so no harm done.

Edited by VernonDozier

Votes + Comments
Well explained and spot-on!
0

but having too much indention could also be a disadvantage

Like??? (Not disagreeing, just want to know what you mean)

Well another advantage of using a recognised style of indentation is that, there are many auto indentation patches or plug-ins for most IDES, which can be used to align a code in a jiffy.

Eg. Since i use Allman style so strictly, when i make a change to the code, which temporarily disturbs the indentation, it can be made normal by just a press of some key combinations.
But one of my friend follows allman effect too, but not fully implement it, he just looks if his code looks ok, not the real rules. And when he gives me a code, and i try to auto align it, every statement goes to the begining of that particular line.

So it looks somewhat like this:

#include<iostream.h> //He is using turbo C++
#include<conio.h>

int main()
{clrscr();
cout<<"Something"<<endl;
cout<<"something else"<<endl;
cin>>something;
etc
etc
etc
}

I use VC++ 2010 and find it really annoying especially with loops and structure, class syntaxs. CJ

1

how do you prefer your code ?

I'm a code aestheticist, so beauty comes a close second to function. Typically I favor transparent code rather than comments because comments tend to make the code uglier unless you do it well. I like consistency (such as indentation and general code style stuff) and balance (one long line in a file full of short lines chafes, for example).

Honestly, I think that if you're worried about the structure of your code, being consistent and balanced is a fantastic start toward writing "pretty" (aka. readable) code.

-1

Like??? (Not disagreeing, just want to know what you mean)

when in each and every tag there's an indention and of course added to that are tabs and spaces, it consumes a lot of lines and empty spaces and it makes the code look the same especially when the changes are so little, it also makes the scroll bar so thin that it would take you time to scroll, even though there's Ctrl+F, it's still...well this is how i see it, so yeah it's like that

Closely related to comments is variable and function naming. Name your variables and functions right and you don't need comments.

yes, that is very important as well .. i'm amazed on how often we encounter that in class discussions but still some students just use whatever word that comes into their mind as variable names, and then asks for help with the debugging, it's just mind blowing ..

0

Python forces you to do proper indentations. Yes, it does make the code easier to maintain.
Comments only if needed for clarity.

0

I don't leave any blank lines, but I like to indent for the sake of neatness. I don't really use comments unless really really necessary.

0

Consistent indentation is really important. I tend to prefer 2 spaces, I don't mind 4 spaces, more is too much IMO. Too much indentation breaks readability of the flow of the code. I tend to use K&R style for braces.

I like line lengths to be limited to about 80 characters (a typical text-area width).

Names of variables, functions and classes should be descriptive, even if it means that they are longer (code-completion solves the problem of additional typing). As for actual conventions (e.g., CamelCase, camelCase, underscore-separated, etc.), I hardly care about it, as long as it is consistent.

The general idea is that when names are descriptive, the code should read like prose, in which case, the need for comments is much less. So, I don't tend to put too much comments inside the body of functions. But, sometimes, when writing a harder algorithm, I write out the steps as comments, which I often leave there after I finished coding it.

However, comments on the interface are hugely important. Documenting what functions do, as in, what are the parameters, what it returns, what exceptions it could throw, and, for mutating member functions, of course, what are the pre-conditions and post-conditions. This is harder to do because it takes time (often longer than writing the code), but I try to do this as much as possible (unless it is really obvious). And, of course, you might as well do it using tags for the relevant document generation system (doxygen (C/C++, and many more), Javadocs (Java), Sphinx (Python), etc.).

And for those who might say that good style, commenting and conventions are mostly important when working in a team (e.g., open-source project or commercial soft. company), well, I always tell them that there isn't much difference between a programmer unfamiliar with your code, and yourself in a few months from now when you will have forgotten most details of your code. So, these things are also important even if you are a lone coder.

Edited by mike_2000_17: typo

0

I like my code (although limited) to be perfect.
As previously mentioned by someone, my code isn't really worth commenting due to the level it is at but I try to comment each section.

As a web developer primarily, I shall write the code out and check it all works and then I shall return later and edit it all out, making sure that everything is in the same order (for example in CSS that the background is at the top followed by the height e.t.c.)

In terms of indentation, I always indent and as others have said and I agree, it makes it a lot easier to read.

0

well indented, well documented and following decent naming conventions.
either the official ones, or conventions on which was decided in-house, and that are used throughout the entire code.

thinking "this doesn't need comments, because it is easy to understand" is abou the worst excuse not to put in that little bit more effort. at least there could be a comment (small is better than none) to generate javaDoc.

having some documentation to read and understand an existing project you're just being thrown into, is a lot easier than to look over every line of code. just go and try if you start in a project which contains thousands of classes, with each hundreds of lines of code. Off course, you don't need documentation on each and every line, but documentation for each method (of which the methodName might seem ambiguous, or doesn't make clear what the method does) is an absolute must.

also: versioned. whether I work on a personal project at home, or at work, no decent version-management? noo touchy before that 'error' has been fixed.

0

I like my code slightly fried over a charcoal pit :-)

Seriously, I summarise at the begining of a function / routine, I comment gong through it, I indent and I use Polish or Prefix notation - Why? because I've lost days after being handed a project that someone else has started (or attempted) and I've been asked to fix / complete it trying to figure out what they where doing, why they did it and what was going on...

I always think that I could get hit by a bus and some other person will have to take over or that three years down the line I'll have to mod the code or build a newer version and I don't want to be spending half my time figuring out what it is doing.

If it is a more complex piece of code or a large project I also use a SDLC and document the whole thing with Tech specs , Functional Specs etc. Again due to past experience. Basically, if I'm coding for a client, and they come back to me and say it is not what was agreed I want to have documentation that they've signed off on to cover my butt maybe I'm just an old cynic

0

I like my code to be incredibly neat, at the cost of space, I have my code spread amongst seperate files to make it easier to read, but that is just me. I also like Indentations heaps, and cannot cod ewithout them. That is why I like code blocks and visual C++.

Edited by Dasttann777

0

I like my code compact, and consistent without too many files and well aligned code. I also gravitate to c-style code like this:

MyGoodHeader.h:

#ifndef MGH_H
#define MGH_H

///@brief Puts the drawing cursor at a specific point in two dimensional space.
/**
    This sets the raster position to the specified coordinates.
    @param x The x-coordinate
    @param y The y-coordinate
    @return 0 unless an error occured.
*/
myErrorEnum goToXY(int x, int y);//X and Y are related, so they go on the same line
TODO document this function!
myErrorEnum drawModel(myModelStruct model,
                      myWindowStruct wnd,
                      myDrawingModeEnum mode);//I hope this ligned up correctly. A monospace font is a must!

 #endif

That should give you an idea. I also cannot stand lines over 80 characters long unless they are absolutely necessary.

PS: What font is used in the code section. I like it.

Edited by Labdabeta: PS and alignment

0

Preferably bug free.

I like my code consistently indented with relevant comments and enough white space to improve readability. Ifindthatnowhitespaceishardtoread but too much white space is annoying and unnecessary.

I find a good process is to first write my modules in pseudocode, then I can turn that pseudocode into comments when I add the actual code.

0

All my code is written bug free - there's no extra charge.

I've been fortunate to work with some exceptionally great programmers. The code they write is generally concise and very difficult to find fault with. However they hardly ever write comments. Empty lines are stripped out to allow more room on screen for code. It seems they have an innate ability to scan and digest code as one might read a newspaper. Comments would only slow them down.

Personally though, I find breaking up code with whitespace can aid understanding, drawing attention to important sections. Isn't it easier to navigate sourcecode when you can clearly see where one function ends and another begins?

0

I find books much easier to read when ideas are broken down into paragraphs and chapters. A great deal of research has been done on effective presentation and has determined the same thing for both books, newspapers and web pages. Monolithic blocks of text are harder to comprehend. The same holds true, in general, for code.

0

To be honest, I am not very organised :(
Stuff like this appears in my code alot:

from random import choice
a = "I"
b = "The stupid cheeser"
c = "He"
d = "She"
e = "The pirate personperson"
f = "killed"
g = "ate"
h = "vomited"
i = "ate"
j = ":)'ed"
k = "The stupid cheeser2"
l = "The moldy cheese"
m = "The cow"
valuec = [a, b, c, d, e]
value_2 = choice(valuec)
print value_2,
valueb = [f, g, h, i, j]
value_3 = choice(valueb)
print value_3,
valuea = [k, l, m]
value_4 = choice(valuea)
print value_4,

No indentation. No comments. Messy Code. Stupidly set values.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.