35

We have many great tools which helps a lot when programming, such as good programmers text editors, IDEs, debuggers, version control systems etc. Some of the tools are more or less "must have" tools for getting the job done (e.g. compilers).

There are still always tools which do help a lot, but still don't get so much attention, for various reasons, for instance, when they were released, they were ahead of their time and now are more or less forgotten.

What type of programming tool do you think is the most underestimated one? Motivate your answer.

Anto
  • 11,197

32 Answers32

69

A rubber duck. Yes, really.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Rubber duck debugging, rubber ducking, and the rubber duckie test are informal terms used in software engineering to refer to a method of debugging code. The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

To use this process, a programmer explains code to an inanimate object, such as a rubber duck, with the expectation that upon reaching a piece of incorrect code and trying to explain it, the programmer will notice the error. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent...

gnat
  • 20,543
  • 29
  • 115
  • 306
Andreas Johansson
  • 1,773
  • 13
  • 18
41

Pen and notebook.

  1. Works without electricity.
  2. Portable.
  3. Doodle on/in when bored in meetings
  4. Store useful information.
  5. If it is written down, people attach more importance to it.
  6. Others can read it and learn.
Sparky
  • 3,065
39

Diff tools seem to be underused when comparing log outputs or data in flat text files. Or maybe that's just a niche? I seem to find it very useful and helpful for debugging to compare huge logs of program executions and pinpoint one or two details that changed.

Performance profiling tools are also very good to have, especially when you hit a critical bottelneck, but it seems very few people are familiar with them (and I admit myself to a degree in this category).

Good XML tools are vital - if you're working with XML files more than a dozen lines or multiples schemas. Sometimes you need more than just basic syntax highlighting other editors provide. Also when working with XML, learning XSL can be very useful. Many times I see what could be done in a simple XSL transform done in many lines in the application's code. Though to clarify: I am not suggesting that XML itself is an "underestimated programming tool"; I am suggesting that the value of good XML editors is underestimated, from what I've seen.

37

Regular Expressions

They are just so useful. They help when searching through log files, parsing text etc.. They are just extremely useful.

I find it strange how many people I know that don't ever use them because there is a bit of a learning curve associated with them. A lot of times I see people do things the hard way (Note: before regex I did things the hard way) when a simple regex could get it down quickly.

barrem23
  • 3,171
24

Your teammates. When you are off on some hot-shot idea and forget to incorporate your team, you'll never hear their concerns or ideas for why it won't work or for why it could be even better.

I say this, because it's easy to think that programming is some antisocial thing people do off in corners with their brilliant ideas. People who think this underestimate the value of teams and their teammates in helping make ideas/projects sink/swim.

Doug T.
  • 11,737
19

Google. There is are very few problems that haven't already been solved and documented. A well-tuned Google query can save everyone a lot of time.

16

Far and away the most underappreciated tool for finding "bottlenecks" is Ctrl + C or the "Pause" button, in a debugger.

Check the last paragraph of this post, and this post, and this post, for starters.

So many times I see/hear of people saying "The program's too slow! What can I do about it? I tried a profiler (if they did), but I don't understand what it says. Anybody got any guesses? Help!" Well, guesses are just that. What I've always done, and others have too, is get it going, interrupt it, and examine the call stack. If the problem is really bad, bingo, it's right in front of you. If the problem is only mild, you do it several times. Anything that shows up on more than one sample, that you can avoid, is a bottleneck you can fix.

Yeah, this is downvote-bait, but it works.

Mike Dunlavey
  • 12,905
14

What type of programming tool do you think is the most underestimated one? Motivate your answer.

The compiler.

Most people don't take time to understand what their compiler of choice does. They just feel that it makes the code into a runnable program and that is as far as they go. On most modern ones, there are several configurations that you can feed into it make it do what you need it to. Here's an example, I bet half the devs in your office have no idea how to set the warning as errors level (assuming it actually has one). What options to do you have to output debug symbols? Which optimizations (or what level of) do you want it to make. The list goes on.

kemiller2002
  • 2,705
10

Your brain. Other tools wouldn't have much meaning without it.

jnevelson
  • 659
  • 1
  • 6
  • 11
9

Good old:

print

Sometimes a debugger or profiler or a UML flow diagram is useful. And sometimes they make you crazy. I always find myself falling back on using print statements (or trace or NSLog or what-have-you) just to make sure my code is doing what I think it's doing when I think it's doing it.

JRW
  • 101
8

Plain old scripts... no matter how many next generation languages we develop we still heavily rely on scripts also most of the day to day tasks can be achieved by writing a few line of scripts.

7

Pen and whiteboard.

You can't beat low tech when trying to explain something.

Andy Lowry
  • 2,422
6

ack. It's like grep -r, but it's designed for seaching through your source code.

5

Perl and other scripting languages. Great for tasks that are just a bit too complicated for GUI tools like Agent Ransack.

kevin cline
  • 33,798
4

Keyboard shortcuts that allow quick, frequent and safe refactoring. Learning how to extract (or inline etc) variables, methods, constants, or classes at the press of some keys fundamentally changed how I code. You will only refactor frequently (i.e. enough) when the cost is minimal, so making these shortcuts second nature is essential to writing and maintaining good code as far as I'm concerned.

So generally, use good tools (IDE/editor) and learn how to get the most of the features they provide.

Unit testing and TDD comes next, to keep your code testable and prevent fear of refactoring.

Use these and you'll easily move towards writing correct maintainable code that conforms to the DRY principle and is self documenting.

Alb
  • 3,359
4

Code generators

Code generators can create a large amount of efficient and bug-free code from a simple definition. ORM type uses are the most obvious for creating data access classes, but there's many more potential uses.

Code generating support seems to still be in its infancy both from a programmer and framework point of view, but I believe it's something we'll see more and more of. In .NET you can start dabbling with the CodeDOM stuff.

Homde
  • 11,114
4

Unit testing offers the following benefits:

  • Developers become the first clients of the code. The quicker a bug is caught, the less expensive it is to fix. Bugs may be caught before a build, install, or deployment.
  • Testing changes your perspective on the code. Is the design clear? Does it handle corner cases?
  • The Hawthorne Effect will improve quality, simply by announcing that a team is publishing quality/testing metrics.
  • Even if tests aren't checked into source control, they can be a great way to explore and learn new terrain.
  • A high probability of fewer bugs!
3

I use AgentRansack heavily. It is a tremendous help searching through thousands of files very quickly. It has saved me so much time, but I don't know of a lot of programmers that know about or use it.

3

Formal Methods.

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

It's hard to overstate their importance. Every loop and every if statement starts out as an idea that requires some kind of "proof". Most programmers do this proof most of the time in their heads. You ask what the if statement does and they can articulate -- soundly and logically -- what the choices are and why the choices are complete, consistent, and exclusive.

But some just seem to guess randomly. They need more help and formal methods could be the kind of help they need.

It's just algebra (and calculus) for code. Nothing too complex or sophisticated.

S.Lott
  • 45,522
  • 6
  • 93
  • 155
3

I think it is Notepad/TextPad/simple text edit programs. Everyone has a time when they need a quick fix that does not require opening an IDE and need just a quick edit. And all computers have some kind of simple text editing program.

3

Physical design patterns like leaving the chair for a quick jog in the sunlight and fresh air keep our brains running at peak awesomeness.

Joe Chrysler
  • 101
  • 2
3

Stack Overflow - quick expert help when you are stuck

question and answer site for professional and enthusiast programmers. It's built and run by you as part of the Stack Exchange network of Q&A sites. With your help, we're working together to build a library of detailed answers to every question about programming...

3

Well it's Half Life 2 (insert your favourite game here). If i got a problem I can't solve I just quit and start playing with my favourite game and suddenly the solution pops in my mind. So to be honest it is not a game or something like that but doing something else. I often see people sitting on a problem for hours without solving it and all they should do is putting their brain offline for a short period.

Adam Arold
  • 1,190
  • 1
  • 8
  • 23
2

Asserts and a good alwaysAssert() function. IMHO these are more important than unit tests, because unit tests can only find bugs in the specific cases you thought to test. If the same programmer writes the code and the tests, he/she will probably miss the same edge cases in both. Furthermore, sometimes unit testing is impractical because the environment in which the component functions and/or the data it operates on is too complicated to come up with a contrived test case for.

The beauty of asserts lies in their ability to document assumptions and test them on non-contrived inputs. If any of these assumptions are wrong, your code fails loudly instead of "working" but producing subtly incorrect results. It also fails closer to the root of the problem than it would without the asserts. In practice, if you explicitly state enough assumptions about a piece of code and all of these assumptions are correct then the code is usually correct.

One common gripe about asserts is that they can be turned off. IMHO every language or standard library should have an alwaysAssert() function or rough equivalent that does the same thing as assert but can't be turned off. This can be used for checking assumptions in non-performance critical areas of code, where the benefits of turning off asserts are negligible.

dsimcha
  • 17,284
2

The F1 key. - Useful for programs you don't know and for programs you are working on. (Assuming that it's a large application.)

Powerful to filter out issues were a users report bugs based on their interpretation of how the software should work. Of course, it could be that the design itself was flawed. But that's another story.

2

Various UNIX core utilities, but primarily find and occasionally grep or ed. The ability to find things in deep nests of files is invaluable, particularly when you suddenly inherit a codebase and have to fix it. Even if said code is well-documented, you will probably have to hunt, and a strong understanding of find kills it.

kojiro
  • 2,095
2

Curiosity

Call it the "Riddle of programming." What is a tool compared to the person that wields it? The desire to know how and why something does or does not work expands one's knowledge more than any specific tool and that is true beyond programming.

Thomas
  • 1,825
2
Ctrl + C    
Ctrl + V

Saved countless hours worldwide!

gAMBOOKa
  • 101
  • 2
1

Tail

Tail can be used to monitor program log output file in realtime. It has been of great help when developing for systems that doesn't provide others means of reading the log.

Example programs are;

Statement
  • 235
  • 1
  • 9
0

I kludged together a Perl call graph generator once. It was extremely useful, but fell over hard on non-procedural code or out-of-file routines.

Paul Nathan
  • 8,560
  • 1
  • 34
  • 41
0

I often work on large teams with projects with hundreds or even thousands of source and headers from all sorts of random libraries that someone thought to throw into the mix.

To locate files quickly, I build custom locate databases against the source tree. This can be very helpful when the source is in ClearCase or the source is in networked file systems usually skipped by the locate command in /etc/cron... Building custom locate databases also helps eliminate all the other files that locate will typically find and place in its database.

On Windows, you can use Cygwin's locate port and at to do the same thing.

0

Valgrind. It saved my life more than once. For some bugs and leaks, I have no idea how could I ever had fixed them without Valgrind.

ggambetta
  • 1,214