• Forum
  • Lounge
  • Hey can i get an example of ugly code an

 
Hey can i get an example of ugly code and beautiful code? is the ugliness of a code objective or subjective?

Pages: 12
Im still not sure if i know the difference, i know theres presentation but'yuck' is a common response after seeing my code, and after ive indented it and auto tidied it, how can i make it more beautifuller? i want it to make you weep but for good reasons
Last edited on
closed account (1yR4jE8b)
sfml-dev.org

Take a look at the source code for SFML, that's some of the best written C++ I've ever seen.
Agreed @ sfml. It's simplicity and clarity is stunning.

Anyway it's hard to say how to improve your code without seeing what's wrong with your code. Can you post an example of what people think is ugly? If we see it we can suggest how to clean it up.
It's almost completely subjective. The only recommendation that everyone should agree with is be consistent. I mostly follow this: http://www.kernel.org/doc/Documentation/CodingStyle except that I stopped using tabs for indentation and went back to using spaces, because spaces are more flexible.

(edit: if you read it, bear in mind that it's intended for people writing code for the Linux kernel, so whenever it mentions things about the kernel, you can ignore them if you aren't writing kernel code).
Last edited on
closed account (EAUX92yv)
Bad looking code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <iostream>
using namespace std;
int main;
{
int num;
char hi;
cout<<"Enter a number.\n";
cin>>num;
if (num=<200)
{
hi='a';
}
else if (num>200)
{
hi='b';
}
}
return(0);
}




Good looking code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>
using namespace std; //My include statement(s) for this program.
int main;
{
int num;
char hi;
cout<<"Enter a number.\n";
        if (num<200) //An if statement to determine if num is less than 200.
        {
        hi='a';
        }
        else if (num>200) // A follow up else if to see if num is higher than 200.
        {
        hi='b';
        }
return(0)
}


I hope this is what you were looking for.

Last edited on
I like it more like this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <iostream>
using namespace std;

int main {
    
    int  num;
    char hi;
    
    cout << "Enter a number.\n";
    cin  >> num;    

    if (num < 200)
        hi='a';
    
    else if (num > 200) 
        hi='b';

    return 0;
}
Last edited on
You just asked a bunch of programmers about code beauty... that's like asking a group of people with mixed political opinions about how good/bad Obama is. Shitstorm incoming!
cstarter2000 your good looking code looks almost as bad as the bad looking code but that's just me.

Most code just looks bad because people take 10000 lines to do what can be done in 10, not because of formatting. But as long as people understand how to indent/space things out correctly I don't have too many worries there.

(And people forgetting code tags doesn't help either)
closed account (D80DSL3A)
cstarter2000 your good looking code looks almost as bad as the bad looking code but that's just me.


LOL. What's worse is he broke it too!
Where did the previous line 8 cin>>num; go?

Pretty, non-functioning code is usually worse than not-so-pretty working code, I say.
... if it is surprisingly simple yet effective and constructive; similarly, a computer program or algorithm is elegant if it uses a small amount of code to great effect


http://en.wikipedia.org/wiki/Elegance
@cstarter,

You don't even have an entry point in that program, no input, and global namespace -_-
closed account (1yR4jE8b)
@cstarter

The comments in your "good" code are quite possibly the most useless comments I've ever seen.
okay i see, has anyone actually seen any elegant code or stunning code before? i guess there has to be more than a hundred or so lines and need a little experience to see whats so beauriful about it
As darkestfreight said in the very first reply -- if you want an example of elegant code, take a look at SFML.
@devonrevenge
The shorter a piece of code, the more beautiful, as long as it being shorter doesn't make it harder to understand. If a 100 line program has no fewer features and no more bugs than a larger program and is no harder to understand, then it is more beautiful.
i was thinking that a beginner could do the same with a few lines of code as a pro, i mean not often but im looking for the venus de milo of code
I kind of also want to mention that IMO, what makes a code "messy" is less about formatting and more about design/flow.
"Good code" is readable, maintainable code.

For beginners, studying syntax and indenting and style and so on helps develop this trait, but these things should not be emphasized over thinking a problem through.

There will always be disagreements about style considerations, but clear code is readable no matter what the style. (Though some styles do help obfuscate meaning at times... I'm just sayin'!)


/weeeeee!
closed account (EAUX92yv)
I know my comments were pointless, but I needed a short useless program to demonstrate that good code should usually include comments.
Good code doesn't need comments. Code that needs comments to explain what it does is not good code. Too many comments in the wrong places leads to situations where you have code that was recently changed which does one thing, and comments that have never been changed which state that the code does something else, which is infinitely worse than no comments at all (at least when there are no comments, anyone reading the code doesn't have to decide which of two behaviours it actually exhibits - the one they think it does, and the one the comments say it does). You might think that doesn't apply to you, but trust me, when you regularly look at a piece of code which is full of comments, you learn to ignore them. Then, when you change the code, in your mind the comments aren't even there, so you forget to change them.

Comments should be kept to an absolute minimum. There should be one at the top of each source and header file (usually a brief description of the file, its modification history, a list of authors, and license), and then one comment for each entity (but only in the header files, except for in languages that don't use them; these comments should be for software like Doxygen which generates documentation from source code comments). There should almost never be comments within the body of a function, the only exception is when you need to point out something important, but even that should be kept to a minimum (your code should be able to point out important things by itself).

Read about the concept of "self-documenting code".
Pages: 12