Signs of Improvement

[zb0S216C]

What are the common signs of improvement when programming?

[chrisname]

I would guess, the ability to write more complex programs, the ability to write "better" (cleaner, more secure and faster-performing) code and the ability to understand concepts you didn't understand before, as well as the ability to read others' source code (this is something I, after nearly 2 years of programming, still can't do).

[zb0S216C]

chrisname, would you say that reading the C++ standard would improve different areas of programming in C++.

[filipe]

IMO that would be like reading a dictionary to learn a language. You might pick up a thing or two, but it's still a big waste of time. It's best to use the standard like you'd use a dictionary: consult it when in doubt.

[Return 0]

A sign you are improving is when it takes you less time to identify and/or understand the solution to a problem. This is a direct result of experience and why reading alone will not improve your skills.

[quirkyusername]

what Return 0 said. Also, the ability to debug effectively and not just be confused by errors you receive or problems you encounter.

I'd make the point though that you might never think you're a great programmer. 2 years ago I would've looked at my future self and marvled at the programs I'm capable of making now, but now that I'm the current version of me I still don't think I'm any good because my standards are higher. I think no matter how good you get at programming you will aspire to be as good as somebody else. There's such an incredible amount to learn, and that's what I love about programming.

[Return 0]

Additional signs of improvement - You don't meet any of these:

http://sites.google.com/site/yacoset/Home/signs-that-you-re-a-bad-programmer
http://damienkatz.net/2006/05/signs_youre_a_c.html

6. Distrust of code
Symptoms

1. Writing IsNull() and IsNotNull(), or IsTrue(bool) and IsFalse(bool) functions
2. Checking to see if a boolean-typed variable is something other than true or false

Java is all you'll ever need.
You don't see the need for other languages, why can't everything be in Java? It doesn't bother you at all to see Python or Ruby code that accomplishes in 10 lines what takes several pages in Java. Besides, you're convinced new language features in the next release will fix all that anyway.

lol

[Seraphimsan]

Yea I can think of a few people like that :P

[chrisname]

Return 0 wrote:

http://sites.google.com/site/yacoset/Home/signs-that-you-re-a-bad-programmer

I met one or two.

Return 0 wrote:

http://damienkatz.net/2006/05/signs_youre_a_c.html

I didn't meet any.

[cran]

The best "signs of improvement when programming" that I know of is that it finally works. Or were we discussing something else?

[moorecm]

At the highest level, improvement can be seen in the ability to ask the right questions.

[Return 0]

craniumonempty wrote:

The best "signs of improvement when programming" that I know of is that it finally works. Or were we discussing something else?

I wouldn't say it's a sign of improvement... unless you're having major trouble writing bug free programs. I've worked on many systems that work, but were designed horribly.

[chrisname]

I agree; I was playing a game, and I looked at the source and it was awful. There was almost no structure. The worst part was you could see where the original programmer had tried to do all these different optimizations, but the end result was still horribly slowe and it scaled horribly. It was a 2D particle simulator; with no particles being displayed it ran at ~40 FPS (not impressive given the fact it's running on a 2.5 GHz quad core CPU and a reasonably modern graphics card (capable of running GTA IV at ~30 FPS)). If I actually try to add any particles, the framerate drops through the floor. I think if the original programmer had tried to write his code to be elegant rather than fast it would probably scale better and would likely have ended up alot faster, too. I say "original programmer" because the guy who took over the project after it was abandoned wrote really good code; but unfortunately he didn't try re-writing it. Or maybe he did, but, like me, he gave up after he too realized trying to move the tens of global variables around would break everything. I spent hours over the course of several days trying to structure it logically so that chunks of code that had a common goal were in one file (e.g. the particle simulator was in "particle.c", the physics engine was in "physics.c", the UI was in "gui.c", and the horrific 4000 LOC main function (I kid you not) was alone in main.c) but I found that many of the global variables were depended on by more than one file, so it became completely unworkable. So I gave up.

[jsmith]

The best sign of improvement is when you look back at code you wrote a while ago and can't believe how bad it is.

[zb0S216C]

Some of the posts helped me out while some made me laugh. This made me laugh the most:

It doesn't bother you at all to see Python or Ruby code that accomplishes in 10 lines what takes several pages in Java.

[3hM2Nwbp]

jsmith wrote:

The best sign of improvement is when you look back at code you wrote a while ago and can't believe how bad it is.

When you have 10 different VS solutions for the same problem and you feel just a little bit more proud of each revision.

[cran]

When saying "that it finally works" no longer means that the code just runs... better?

[firedraco]

"Email me teh code, plz" messages posted to help forums

Heh.

[Duthomhas]

4000 LOC for a single function! Good grief!

And I thought I wasn't being too picky when I fixed Tcl/Tk's ImgPhotoCmd() function, which was, by most industry standards, very well-written to begin with, but over 900 LOC. That's too much. (I knocked it down to about 60, using a table lookup to branch to support functions to perform the command subtasks.)

I'm a big believer in the "do one thing" and "fits in one screenful" kind of function design.

[chrisname]

Well, I said 4000, I just looked and it's actually 1408 LOC: https://github.com/FacialTurd/The-Powder-Toy/blob/master/src/main.c
I thought it was more, but that's still ridiculous. I could have sworn it was alot more than that, at least 2000 LOC; maybe someone cleaned it up. If you browse the rest of the source tree you'll see that the files added by the guy that took up the project (e.g. http.h and http.c) are well written but some of the other files are awful.

Duoas wrote:

I'm a big believer in the "do one thing" and "fits in one screenful" kind of function design.

Me as well; I try to keep my functions as short as I can, though I'm not _that_ rigid about it. A function being over 100 LOC is a crime to me, however. 60 is acceptable, though I would probably have tried to split it into "helper" functions. If you read e.g. the Linux kernel they have lots of static functions that are only used in that one file, and then at the end of the file they have the function that uses them. It makes it alot easier to read the function when you have something like

int kill_all_processes()
{
        struct process_table* ptable;
        ssize_t nprocs = 0, i = 0;

        if (!(ptable = get_process_table()))
                return -1;
        if ((nprocs = get_process_count()) < 0)
                return -1;

        for (i = 0; i < nprocs; ++i) {
                if (kill_process(ptable[i]->pid) < 0)
                        return -1;
        }

        return 0;
}

rather than have all that code in kill_all_processes.