Thread: How to more intuitively wrote more elegant c++ code?

When writing programs, my code tends to be very inelegant; I just have very little intuition for writing code that isn't longer than it needs to be.

Is there anything I could do to improve my thinking, so that when I write a program, the code isn't so ugly right off the bat? I already know about pseudocode, but my not-too-ugly pseudocode tends to get translated into very ugly actual code.

I also feel like elegance is dependent upon your skill level as well as your overall knowledge of C++.

I think that on the quest to inner peace as a programmer in general, you should write something you think is elegant now and come back to it later and gasp in horror and its absolute inelegance. Then refactor it until it's once again become elegant. Rinse and repeat this process until you retire.

I feel like for a lot of your problems that I've seen, elegance is the same as knowing how to solve it more or less. For example, in this problem all you really need is a function that determines if a number is prime and a decent algorithm to find the prime factors of a given number.

Sure, I could write a solution in fewer lines, and I have, (It runs in about 1 second! XD) but if you take a look at the components of the answer, it has the same functions. So what basis do we have to say your code is inelegant?

On top of that, some people would prefer a program with all of these bullet points addressed:

• There is no vector of all the integers found.
• Another way to write the program is to use remove_if() from the STL to reduce a larger vector containing all the integers below 1,000.
• The only way to reuse the IsPrime() function and GetFactors() function in another program is basically to copy and paste currently. These components ought to be reusable.

To address these points, you basically have to re-write my program but there are reasons not to like what I did. What you should take away is that elegance can be more about hitting a certain sweet spot.

Going off what whiteflags said, I'd also recommend embracing the STL as much as possible. The STL is expressive and decently performant. Honestly, until you have a proven bottleneck, I'd make the assumption that the STL code will be "fast enough".

But yeah, modularize. Separate interface from implementation by pulling things into well-named functions.

Also, write tests. Write. Tests. If you are going to refactor code at any point in the future, you better have a test-suite backing it up. Tests are great because they also force you to write code that is a) easily testable and b) they test your code.

Reading code is also a good way to get better but Lord help us all, C++ is one ugly language.

Originally Posted by MutantJohn

I think that on the quest to inner peace as a programmer in general, you should write something you think is elegant now and come back to it later and gasp in horror and its absolute inelegance. Then refactor it until it's once again become elegant. Rinse and repeat this process until you retire.

This is what I've done with code I decide I'm going to keep. Review as best I can, go back and look at it again a few days later, look at it again in a month or two, until I settle on it being good.

Originally Posted by Elkvis

Give us an example of your raw code, and we can come up with ways to improve it.

Well, I dont need to know how to improve a specific program I wrote; I just asked for tips on writing programs shorter than they need be. But if you need the best example of my inelegant code, look here: http://cboard.cprogramming.com/redir...2Fe2cc640466d5

Though in my defense, that problem was far too advanced for the chapter it was introduced in; never seen a good solution for that that didnt involve recursion. Keep in mind that recursion was taught well after that point in the book, so yeah ^^;

Originally Posted by GReaper

Don't beat yourself up about it. To write elegant code, you need experience. Planning plays a critical role in big projects, but single-file solutions can be just mentally mapped/planned and the code flows out of your fingers without even thinking about it.

All right. I certainly dont have much (if any) meaningful experience.

Originally Posted by Elkvis

A few very important things to keep in mind any time you write code:

Consistent indentation and formatting.
Descriptive identifier (variables, functions, classes, etc.) names.
Keep functions short - ideally no longer than the height of your screen.
Keep functions simple - one purpose and responsibility.
Avoid global variables, and prefer passing things around as parameters. If you must have a global variable, consider making it a static member of a class or struct, or wrap it in a namespace, possibly named "globals."

I got all of those except the third and maybe fifth one.

Originally Posted by MutantJohn

I also feel like elegance is dependent upon your skill level as well as your overall knowledge of C++.

I think that on the quest to inner peace as a programmer in general, you should write something you think is elegant now and come back to it later and gasp in horror and its absolute inelegance. Then refactor it until it's once again become elegant. Rinse and repeat this process until you retire.

I get what you mean about skill and overall knowledge, but what if I write a program for the first time, and think its ugly?

I get what you mean about skill and overall knowledge, but what if I write a program for the first time, and think its ugly?

For one, write tests that verify the behavior.

Then refactor, refactor and refactor.

Run it through your tests and make sure you didn't break anything.

By "write tests", you could always do what I do, just fill your main with a bunch of calls to functions that are full of assert statements. I know there are some frameworks out there but for me, I don't mind just assert statements that are ultimately called from the main.

Tesp, most of your posts at bpaste have 404'd. I thought you should know.

Originally Posted by MutantJohn

For one, write tests that verify the behavior.

Then refactor, refactor and refactor.

Run it through your tests and make sure you didn't break anything.

By "write tests", you could always do what I do, just fill your main with a bunch of calls to functions that are full of assert statements. I know there are some frameworks out there but for me, I don't mind just assert statements that are ultimately called from the main.

I have written simple tests for all my assignments, but I'm not yet familiar with assert statements. I'll use those when I learn them. Thanks

Originally Posted by whiteflags

Tesp, most of your posts at bpaste have 404'd. I thought you should know.

Odd. Thought I set the expiry to "never". Well, I can't edit those past posts, so I guess I'll have to leave that as is :/

I have written simple tests for all my assignments, but I'm not yet familiar with assert statements. I'll use those when I learn them. Thanks

All they do is crash your code if what you pass in isn't true.

For example,

Code:

assert((1 == 2));

will just flat out crash your code.

This is useful in testing because if you write a function that is supposed to remove all odd numbers from an array, it's really useful to test it by doing this:

Code:

for (auto a : my_array)
    assert((a % 2 == 0));