Sorry, my mistake. Like I said - confusing thread.
Printable View
Sorry, my mistake. Like I said - confusing thread.
I think this thread should be removed so that we may all look that much smarter again.
Yeah, both of you confounded me. Surprisingly, Bubba even did it again, even after I already mentioned that little problem that was causing the trouble.Quote:
Originally posted by Bubba
Sorry, my mistake. Like I said - confusing thread.
It's your fault that I've got a very unique avatar now. :mad: :mad: Phear me. lol :)
Once you learn C (or C++) and start programming, you'll find 2 things:Quote:
Originally posted by darksaidin
I based my opinion on the visual appearance of C code I found in tutorials on this and other sites. Perhaps you like the massive amount of prepercessor code in C apps, or all those ___ things (no clue how it's called in english). I don't.
1) Well-written code looks beautiful -- it's easy to read and understand at a glance, and has that beautiful "QWAN" that people talk about.
2) Most code, and in particular most tutorials, tend to be badly written. Unfortunately, most people learn wrong from the start, and not a lot of people go back to learn how they should have been doing things. I've programmed in C++ for going on 13 years now, and I still learn and improve my style regularly. Tutorials tend to be contrived, and many focus so single-mindedly on demonstrating one task that they use horrible code throughout. They're OK if you are only trying to learn that one task, but if you're trying to learn style, they're not usualyl good at all.
I don't think it's a unique quality of C++ that most code is badly written. In fact, language doesn't contribute much to beauty at all; most of the beauty or ugliness comes from variable names, comments, and the underlying logic. I've seen programs written beautifully in MIPS assembler and ones in visual basic that looked like crap.
Languages are tools; the art of programming is how you use the tools, not how you choose the tools. Of course that only holds so long as the tool you choose is appropriate to the task at hand; some tasks lend themselves better to one set of tools versus another.
This is one of the better pieces of code I could find. It's not a good example of awful code, but I didn't want to overdraw (w?) the problem.
Is that beautiful? It's a terrible mix of "__", "<", and "{". I don't know why templates look like a corrupted HTML file (using < and >), to be honest I don't even know what a template is or why it looks that awful, but it's certainly not what anybody could call beautiful code. Not because the guy who wrote this was a bad coder but because it just has to look that bad.Code:namespace std
{
template<typename _CharT, typename _Traits>
streamsize
__copy_streambufs(basic_ios<_CharT, _Traits>& _ios,
basic_streambuf<_CharT, _Traits>* __sbin,
basic_streambuf<_CharT, _Traits>* __sbout);
// 27.5.2 Template class basic_streambuf<_CharT, _Traits>
template<typename _CharT, typename _Traits>
class basic_streambuf
{
public:
// Types:
typedef _CharT char_type;
typedef _Traits traits_type;
typedef typename traits_type::int_type int_type;
typedef typename traits_type::pos_type pos_type;
typedef typename traits_type::off_type off_type;
// Non-standard Types:
typedef ctype<char_type> __ctype_type;
typedef basic_streambuf<char_type, traits_type> __streambuf_type;
typedef typename traits_type::state_type __state_type;
friend class basic_ios<char_type, traits_type>;
friend class basic_istream<char_type, traits_type>;
friend class basic_ostream<char_type, traits_type>;
friend class istreambuf_iterator<char_type, traits_type>;
friend class ostreambuf_iterator<char_type, traits_type>;
friend streamsize
__copy_streambufs<>(basic_ios<char_type, traits_type>& __ios,
__streambuf_type* __sbin,__streambuf_type* __sbout);
[...]
Another thing is the use of { and } to mark program blocks. I really love the way this is done in C. It's a lot better than begin and end, especially since this can be used even for loops whereas begin and end in delphi is only used if the loops condition check is on top of the loop. So thats something I think has been solved better in C than it has been in Delphi.
But what do I see next ? public: without any idication that a program block is about to begin. Same goes for select case blocks. Select can mess up your programm really fast if you forget just one break;. {} are allowd in case blocks, but not needed. Inconsequent.
The excessive use of __ is not really beatiful either. Again I have no clue why it is done, but I don't like it. Of course thats just my personal opinion. Always reminds me of "fill the gaps", if you know what I mean. 1. grade...
Just look at the last two lines....
This wasn't even the worst piece of cr.. code. However I think it is enough to underline my statement: C code is not beatiful.
Yay, I think I finally made it. This thread is dead. Long live the thread....
Beauty is in the eye of the beholder.
Yet again, you imply that DB is dumb without reason or cause. Why? This I do not know. *sigh*Quote:
think this thread should be removed so that we may all look that much smarter again.
Templates look confusing at first, but they're not that bad once you learn to read them. The templates you used as an example are part of the standard library; they're confusing and long because there are many requirements of standard library containers. In fact, there was no actual code there, only typedefs and one function declaration.Quote:
Originally posted by darksaidin
Is that beautiful? It's a terrible mix of "__", "<", and "{". I don't know why templates look like a corrupted HTML file (using < and >), to be honest I don't even know what a template is or why it looks that awful, but it's certainly not what anybody could call beautiful code. Not because the guy who wrote this was a bad coder but because it just has to look that bad.
Well, there is reason to not break by default; it allows multiple cases to share the same code. E.g.:Quote:
But what do I see next ? public: without any idication that a program block is about to begin. Same goes for select case blocks. Select can mess up your programm really fast if you forget just one break;. {} are allowd in case blocks, but not needed. Inconsequent.
case-switch is indeed one area of code that tends to be buggy.Code:switch(cInput){
case 'Q':
case 'q':
case 'X':
case 'x':
Cleanup();
break;
case 'n':
case 'N':
NewFile();
break;
}
They do that because only the vendors are supposed to use anything beginning with _ or __. Compiler vendors often want to supply the user with more functionality than the standard guarantees. By using variables, macros, defines, and functions beginning with _ or __, the compiler vendor can ensure that their macros don't have the same names as user-written ones, which are not supposed to begin with _ or __.Quote:
The excessive use of __ is not really beatiful either. Again I have no clue why it is done, but I don't like it.
E.g. if my compiler provided a macro called DBGTRACE(), it might conflict with a macro or function I had written. By naming it __DBGTRACE(), a name I'm not supposed to use, there shouldn't be two things with the same name (and if there are, it's my fault for using a name I'm not supposed to).
There are other examples. Let's create a new structure.
Looks nice so far. Now let's use it in a function...Code:struct t3fpoint {
float x,y,z;
}
So now we have a really ugly function. It's so ugly that someone decided to invent #define. :) To make things worse, C editors will highlight "struct". At first glance you'll think this is a struct definition and not a function. So it's your choice: Ugly functions or ugly metacodes in your header?Code:struct t3fpoint add(struct t3fpoint a, struct t3fpoint b) {
struct t3fpoint c;
...
}
But of course thats again just my opinion. Actually I don't really like any of the existing languages. I could list a lot of problems in BASIC or Delphi, too, but that would be even more offtopic :D
If you ask me, even ptr->field is ugly (not from the looks). It's not in line with *ptr. Thats why I'll always use (*ptr).field. Doesn't look particularly beautiful either, but at least it's consistent with the way normal pointers look like.
I know, my glass is always half empty, never half full... I gotta live with it :)
Admittedly I haven't programmed C in many years, but I believe the following is legal C:
which looks a lot nicer, no?Code:typedef struct {
float x,y,z;
} t3fpoint;
t3fpoint add(t3fpoint a, t3fpoint b) {
t3fpoint c;
/*...*/
}
And #define is ugly; it has its places, and it can do things that nothing else can get done, but it's easy to abuse; typedef is a much better solution.
I personally like the -> much better than (* ). , but maybe that's just me.
If that works, it's one point for you.