I am preparing for a programming contest where we have to code in C++ and it is all about producing working code in a short time. An example would be to use a macro to get the minimum of two ints or using memsets to initialize arrays (but I was told that you shouldn't use either here).

This leads to the question: what kind of coding techniques exist to speed up coding at a real job?

Answer: Know your STLs (13 Votes)

Review the standard libraries intensely, particularly the STL algorithms. This will save you many lines of code and a lot of time. The key to winning programming contests is in programming at as high a level as possible. In C++, without external libraries, this means STL calls instead of for loops.

Answer: Veteran advice (5 Votes)

I participate regularly in ACM competitions. Hopefully some of these tips will help you:

As others said, familiarize yourself with the language, in C++, especially the STL, it has both common functions that you'd want to use (binary_search, min, max) and robust data structures to save you time (stack to avoid straight up recursion, queue for BFS, even priority_queue for Dijkstra if you like it that way).

Identify the category of the problem, if it's mathematical / dynamic programming / graph theory etc. Ask yourself how familiar are you with it. After doing this you should make decisions regarding the order in which you'll solve them; this goes hand to hand with the next point...

You want to understand the problem completely before typing. Solve the right problem. In my first competitions I thought that if I wasn't typing, I was wasting my time. I later found that this was a mistake.

Don't think comments are a waste of time. At least in "clever" code, you don't want to go debugging line-by-line to see what went wrong (that is a real waste of time). Value clarity.

"I would recommend a book. We kindly present only the books worth reading, instead of those that teach C garbage."

thanks to this line right here Bezos will make over $200 from this fool

your comment annoys me with its ignorance. He may very well have been saying there are C++ books which claim to teach C++ but really teach C with occasional objects, which would be C garbage by definition. C is a good language and C++ is good too, but know which you're using.

Aye. Left unsaid is "choose your books wisely". Good general programming books are duplicative. SO has a good list. Read reviews. Visit brick&mortar Barnes & Noble or whomever, and buy the good book that fits you. I have over a dozen worthy C++ references in my library in the other room. On the shelf next to my desk live the four I actually use, the ones that work for me.

"Teach Yourself C++ 7th Edition" Al Stevens. Fell in love with the guy's style back in his Dr. Dobbs days. Stuck with him.

"The C++ Standard Template LIbrary" Plauger, Stepanoff, Lee, Meusser. First STL reference that was readable by me. No reason to change.

"Advanced C++ Programming Styles and Idioms" James Coplien. Took an Advanced C++ course once from an old-line Murray Hills dude and Coplien accomplice. Never thought I'd ever need this stuff. When I did, I needed it bad.

\"(More\s)?Effective\s(C++|STL)\" Scott Myers. 'Nuff said.

"C a Reference Manual" Harbison and Steele. Just as concise as K&R, and I like CARM's organization better. Either way, there's no excuse for not knowing the C fundamentals. Faded and tattered.

"Programming with Posix Threads" Butenhof. At this point the Astute Observer might observe a "good" modern C++11 reference might open new horizons and save some shelf space at the same time. The Overflow list includes the latest C++ Primer from Lippman, Lajoie, Moo, and Overview of the New C++ by Scott Meyers, so at present the set remains denumerable enough from which to make a choice, though perhaps not so denumerable from which to make a "good" one

Best of all, do an other contest where the language of choice is NOT C++.

This is probably the worst language (right there with Basic and Cobol) to do anything that works and is debuggable quickly. It is also a language for which all the IDEs that I have tried suck, and a good IDE is your first route to speed up your coding in any language.

Since when has programming been done against a clock!? Yuck. Anything you could do in a short time slice has probably already been done in a library or an online snippet. I'd suggest working on interesting problems.

Best of all, do an other contest where the language of choice is NOT C++.

This is probably the worst language (right there with Basic and Cobol) to do anything that works and is debuggable quickly. It is also a language for which all the IDEs that I have tried suck, and a good IDE is your first route to speed up your coding in any language.

You've got my attention. What magical programming language...

-Is Quick and Easy to debug-Has better IDE support than C++-Is not prone to programmer error(which is what I take "to do anything that works" to mean)

hey, I know lets write it in C... no, wait, although I know that its a slow productivity language. Lets write it in C++, that.. no wait, lets write it in Java that give us much more.. no wait, lets write it in C# MS has made some great tools that... no wait, lets write it in Ruby, that's a fantastic new, no wait.. lets write it in Python cos everyone says that that is so much more.. no wait, lets write it in Haskel cos anything done in that gives us productivity and perf... no wait, lets write it in Node.... no wait.... fuck it, lets write it in C, than at least I'll know it'll work and will be able to maintain it for years to come.

The thing with programmer productivity is NOT the language, its the skills and expertise that you build up over time. Combine them with all that code you and others have already written and you get productivity. Not by swapping to whatever new tech happens to be fashionable.

Best of all, do an other contest where the language of choice is NOT C++.

This is probably the worst language (right there with Basic and Cobol) to do anything that works and is debuggable quickly.

You've got my attention. What magical programming language...

-Is Quick and Easy to debug-Has better IDE support than C++-Is not prone to programmer error(which is what I take "to do anything that works" to mean)

Either C# or Python would qualify. Anything that protects you from alloc/free issues and hand coding really common idioms (though the STL helps with that a lot). And depending on what you're working with, has decent string processing.

I use C++ a lot when we need speed (or are dealing with existing code base) and I'm pretty decent at using STL and templating, but I can still get things done 10x faster in Python or maybe 5x faster in C#. STL is great but the syntax is still horribly cumbersome.

Another big time sink in C++ is writing the .h files separate from the .cpp files and how the syntax of every single method declaration is slightly different for the .h file than it is for the .cpp file, and how you have to keep them in sync whenever you add anything... neither C# or Python have this problem.

Finally, when debugging, it's usually much easier to find out where something is wrong in Python since the language is very readability focused (at some cost of writing speed), and you can focus on finding your logic error. To make this clearer, my Python errors are almost always in logic, while my C++ errors are very often language 'gotchas' or syntax. Edit: Oh, and you can change your Python on the fly while debugging, since it's interpreted!

Not saying C++ is horrible or Python is best for everything (there's a place for each, I use both daily), but if the primary goal is getting something working fast I'd choose Python every time, or C# if it's heavily GUI. I detest VS 2010's horrible obfuscating project/solution system, but the form builder makes everything so easy.

Anything that refers to the speed at which you're coding and urges you to be faster makes me cringe.

Trencher93 wrote:

Since when has programming been done against a clock!? Yuck. Anything you could do in a short time slice has probably already been done in a library or an online snippet. I'd suggest working on interesting problems.

Welcome to the world of contract coding, where every minute spent coding is billed to a client at 5 times your own hourly rate, and they have tight budget constraints due to tough competition in the industry (the cheapest quotes get most of the work).

Also, bugfixes are often not billable at all. So even though I'm meant to code as fast as I can, my code is also expected to continue working for *years* with almost no bugs. My manager is much happier with late/over budget code than buggy code. So, we still write pretty good code even though it's done quickly.

TDD for a programming speed contest? Ummm, no. Right tools for the right job. TDD is about elegant design and maintainable code. Neither of those or going to help you win a speed programming contest. The benefits of TDD are for long term projects. The longer the project the more TDD benefits. A programming speed contest is about as far in the opposite extreme as possible.

No matter how fast you code but what to do when the functions don't compile? So use your own libraries if you're allowed. Be able to use your own libraries - is a short cut. Nothing beat that.

Something about the pic. An ancient oriental imperial structure design on the background with a bunch of modern computers bow on their knees before the emperor on the foreground makes it looks like the oriental emperor is still the lord of the modern technology at this 21 century. What the pic is trying to say to us? I wonder.

"Yes, I bow to you, my lord, "

To his custom outfit, the emperor looks much like the one from the Qing Dynasty.

An out of the ordinary graphic design though. Love it. (saved it for my wallpaper.)

I did one of those contests once. Coding fast wasn't as important, it was about forming algorithms quickly. You needed two kinds of people on your team: Algorithm writers and coders. And they need to be able to communicate.

My advice: Go through every previous year question and force yourself to answer it.

My advice: Go through every previous year question and force yourself to answer it.

Precisely, in fact do ALL the past competition years that you can get your hands on. Know the rules in advance, have your tools ready (IDEs, debuggers, also books, custom routines, code examples, etc), whatever is allowed. Ideally you should only need the first two though, the rest should be in your head already Practice, practice, practice... together as a team as well.

It all depends on how much time you will have (how big the project is). If it is a matter of say 5 minutes vs 5:20 per problem, typing speed and quick and dirty shortcuts are essential. No time for nicely formatted code then. Hard to do teamwork this way though, so probably your comp will have bigger/longer tasks. Leaves you time to think before you type, so use it - and make sure not to reinvent any wheels. You got good advice for this case already. I would only add that if you not only need working code but also computed results by the deadline, choosing reasonably efficient algorithms could be critical (again depends on your competition). In that case have people on your team well versed in algorithms, numerics, whatever the nature of your contest requires.

If you are free to choose language, make sure to know a handful and have experience with what is faster/easier to do in which language. You can get some ideas about this if you practice solving the same problem in different languages. Combining C/C++ with shell scripts, AWK, perl, etc, could save time.

In any case, good luck - you will definitely learn some new tricks and will have fun along the way

What greggman says: TDD is so not for speed programming. TDD is overhyped, but in itself not a bad idea for software development. However, it does not guarantee anything: if you don't know how to structure your problem, how to write good tests, or how to make different tests cooperate to cover the whole problem, you're lost. TDD in that sense is a mix between bottom-up and top-down design. It's not optimal, it's not for all situations, and the danger exists that all your tests pass while the code is an enormous mess. It's also not fast. However, if you do it properly, it can be a great help. It can catch stupid coding errors early that would be impossible to discover later, errors introduced by a simple refactoring, etc. So why the top answer got so many votes, is a riddle to me.

Best of all, do an other contest where the language of choice is NOT C++.

This is probably the worst language (right there with Basic and Cobol) to do anything that works and is debuggable quickly. It is also a language for which all the IDEs that I have tried suck, and a good IDE is your first route to speed up your coding in any language.

Empirically known to be bullshit.

On topcoder where I participated a couple times (#2nd and #5th place on marathon matches), there's multiple languages allowed. Do we see the top spots taken by, say, C# and Java all the time with no place for C++ ? No.

My advice, btw, based on doing contests: try to think clearly when you code. The better you understand what you're doing the less time you spend debugging. If you do mathematics by experimentation, you aren't going to get anywhere in algorithmic contests. If you are not sure if something is going to work or not, take the time to learn to be sure. The time that has to be spent debugging is very variable between different programmers. One programmer could write a couple hundred lines and then waste days debugging, another couple hundreds, few days debugging them and then few more days fixing up bugs that arise when codes are combined, rinse and repeat, and then still have a lot of bugs. Other programmer can write entire thousand lines and have it working correctly on first compile.

Know your language and STL goes without asking regardless of whenever you code fast or slow.

edit: ahh, and assertions. Use them. Sometimes, write functions that verify output of other functions, make those run in debug mode. Write functions verifying complicated data structures for integrity (those can, when simple, double as specification for what is correct structure).

I used to do competitions in HS and it was usually fun and somewhat challenging.

After making it a career though, I don't think I could draw any enjoyment from seeing who could code the fastest. To me it seems like, "Yes please award me for writing the most awful, un-maintainable, spaghetti code that took me 129.3 seconds to write!!"

"I would recommend a book. We kindly present only the books worth reading, instead of those that teach C garbage."

thanks to this line right here Bezos will make over $200 from this fool

your comment annoys me with its ignorance. He may very well have been saying there are C++ books which claim to teach C++ but really teach C with occasional objects, which would be C garbage by definition. C is a good language and C++ is good too, but know which you're using.

Sometimes to try and work faster I’ll just start typing instead of thoroughly planning what to type first. Then spend time fixing mistakes or have an overly complicated way of doing something. In these situations, when I sit back and think about the problem thoroughly first, I code faster.

Anything that refers to the speed at which you're coding and urges you to be faster makes me cringe.

In my college days, I participated in a few ACM contests. Are they a good test of real-world programming skill? Not really. Are they a fun and challenging way to kill a few hours for people who are into that sort of thing? Hell yeah!

And to all the C++ haters: ACM contests (which I assume this is… it does sound eerily familiar) are more about testing your problem solving abilities and knowledge of CS than anything else. I don't remember any of the problems taking volumes of code to solve. Even in C++, the answers were usually fairly short: on the order of 100 lines or less. These aren't your 100,000,000 LOC "Enterprise" projects. Really, they're more like interview questions than professional programming assignments.

Programming contest? I think many of the above posters have never tried one before - they're actually algorithmic problems for the most part, designed to be solved fairly quickly. Profilers, TDD, IDEs, and very high-level languages are not of much use here - there is no fancy user interface, complex data parsing, or multithreaded twiddling that would make a C++ programmer want to cry.

DO:- NOT write C++ (with some exceptions [not C++ exceptions] ) - it's too much work and C++ does NOT help organize 200 line programs.- Write C instead, but use STL and other C++ libraries if convenient. But keep simplicity in mind - don't use STL to do things that can be done with ordinary C arrays/pointers unless you want to read pages of compiler errors when you make a typo.- Don't dynamically allocate memory unless you really, really need to. Global variables are OK if you're afraid of stack overflow.- Have a few simple test cases.- Know how long your program will take to run - as a rule of thumb with C you should not expect more than 100 million simple operations (eg. addition) per second. For example, you should not write O(n^2) algorithms if n > 10000. Just count your loops and know how long more expensive things like std::sort take.- Think before you type. No use cranking out non-working code.- Know how to debug a program, maybe with a debugger's help.

READ:- "The C Programming Language"- an STL reference, and maybe a C++ tutorial so the usage makes sense- an algorithms book - this is the most important. A good one is "Introduction to Algorithms."

they're actually algorithmic problems for the most part, designed to be solved fairly quickly

I bet you are probably right, though only the OP could tell. The ones I had my chance to ranged from 2 hours to 72 hours, so were not that simple. TopCoder was mentioned here, so I checked one problem there, a simple sorting-matching type (MatchMaker or whatever it was called), and the winning solution was submitted in 6 minutes and 20 seconds, in perhaps 30 lines. Funny why I thought of teams originally, I think some of the replies discussed them. If he/she has this blitz type of coding in mind, trying those short TopCoder problems and then checking against winning solutions could be useful preparation.

Actually there were two divisions, and the winner in the other division did it in 9 minutes or so. With cleaner code, in my opinion, but 3 minutes too late

Don't under-estimate the value of psuedo-code. Before I start any coding, I'll either flow-chart or outline what I want the program to do. You're building a machine. When you draft it out on a napkin, you can immediately see areas to optimize or alter... or even eliminate.

This is true in anything you do, really. Friends of mine and I would do our own rpg engines. Ended up writing tons and tons of rules, etc. What we realized after writing gobs of rules was that we were recreating the exact thing we hated in current rpg's... overly complicated rules. We were recreating a life simulator instead of an intangible, free-form rpg engine. When we finally focused on our goal, we ended up trashing 90% of what we created.

Measure twice ... cut once. Don't lose focus. If you fail to plan, you plan to fail. All that crap.

You should keep your codes clean, for example, not to have a bunch of meaningless comments, to make code easier to read. When code is clean, code is much easier to maintain (trust me, I'm in charge of maintaining 10-yrs codes and it's nightmares). For this topic alone I think 'Clean Code: A Handbook of Agile Software Craftsmanship' by Robert c. Martin is worth reading.

Another thing is you should also uses common design pattern. So when people read your code, including yourself, they would understand your code faster since the design is so common. Beware, though, if the inappropriate pattern is used for class/structure, it would results in codes that is very hard to read. At least you should have Gang of Four's 'Design Patterns' on your desk (and don't forget to study it).

Use common/standard library as much as possible, but not too much. These libraries are well maintained, so you don't have to do it yourself.