How do you write "boring" code?

Question

Sometimes, we have to write some really trivial code, such as enable/disable controls.

EDIT: I don't want to ask how to fix my problem, it's just an example. I want to ask how you deal with "boring" code?

For example, I now writing a Windows Forms application, and depending on the user's choice, controls get shown or hidden. My application contains a lot of code like this:

bool bShow = comboBoxModes.SelectedIndex > 3;
            labelFrom.Visible = bShow;
            labelTo.Visible = bShow;
            dateTimePicker1.Visible = bShow;
            dateTimePicker2.Visible = bShow;

How do you write such "boring" code like that?

Answer 1

Put it into a function that takes references to the objects, and use the function instead. That avoids repeating the same kind of code over and over, and improves your productivity.

For example...

bool bShow = comboBoxModes.SelectedIndex > 3;
            labelFrom.Visible = bShow;
            labelTo.Visible = bShow;
            dateTimePicker1.Visible = bShow;
            dateTimePicker2.Visible = bShow;

Can become:

someFunction(comboBoxModes.SelectedIndex > 3, new object[] { labelFrom, labelTo, dateTimePicker1, dateTimePicker2 });

There's naturally better ways of passing the objects and all that, but you get the idea. I'm not necessarily trying to show you correct code but rather a generic algorithmic approach.

---

EDIT: I don't want to ask how to fix my problem, it's just an example. I want to ask how you deal with this?

Basically, I look at the repetitive elements of the code and try to find out if there's a way I can save lines of code by using a generic function to do it for me. Once I've found some type of relationship I write the function and refactor the repetitive code.

Answer 2

You mean without getting bored? You can't. But you can eliminate as much duplication as possible by following DRY principles.

Answer 3

One keystroke at a time. Not all coding is glamorous and interesting. Sometimes you just have to suck it up and write tedious code. There might be things you can do to reduce the amount of code that you have to write. Perhaps all the controls are in a container that can be disabled instead? Whatever you do though, don't get too clever and make these simple yet tedious tasks become maintenance nightmares.

Answer 4

Off the top of my head, in C++ you have:

labelFrom.Visible=labelTo.Visible=dateTimePicker1.Visible=bShow;

Usually I just write it like you did - no mind work involved so enjoy the little rest in the midst of coding :D

Answer 5

If you want to write boring code the do freelancing. You can choose what you want to code.

Answer 6

I wouldn't use the variable bShow.

If the values changes more than twice in an app, I would throw them into a procedure that would be called when they all need to be changed.

For you, I'd put procedure to be called from within the SelectedIndexChanged event so that you can evaluate it's above 3 and then call the procedure to set them all to true and vice-versa.

If you're trying to get an idea if we write this kind of stuff, of course, we all have to at some point or another.

Edit: VB doesn't have the same type of lambda functions that C# has right? Like what Matt Iselin put?

Answer 7

Boring code happens after you've written brilliant reusable code. It's inevitable, like maintenance.

Answer 8

I like Matthew Iselin's answer, although sometimes it's very difficult to write a ultimate generic algorithmic approach. In that case, your editor comes to play a nice role. Stuff like macros and Regexes can make your life easier. Try Vim or Emacs for example. Even NetBeans has macros.

Answer 9

I put on headphones and turn up the music really loud.

There are always trivial/boring parts of any project. Hopefully you don't get too many of them. There is probably always a better/more interesting way of coding any given task, but don't turn trivial code into something that its not. Keep It Simple.

Answer 10

Use a decent editor that allows you to rapidly produce patterns like this one.

Answer 11

Realize that what you do is create value for customers. If that means writing boring code, then write it in such a way that you can spend the minimum time necessary maintaining it in the future. If that means getting coffee for the rest of the team, as they're on a critical path and you're not, then DO IT. That's what being a real professional is about, not writing really awesome glory code (that more often than not becomes a maintenance nightmare).

A sign of proficiency and good design is when all code becomes boring code.

Answer 12

If it is boring because you are basically copying something that is done somewhere else, refactor your code and make it a function.

If it is boring because you are not quite copying something but modifying it enough so that it can not be parametrized, use higher level programming like reflection, or write a script that puts out code.

If it is boring because higher level programming is not available or you can not write a script that puts out code, remember that you get paid for your work, either with money or personal reward, and pull it through.

Answer 13

Mate, bribe your kid brother to write it.

Answer 14

Actually I used to have this same problem, my first summer job (in 1977) was writing COBOL, and it took everything that I had loved about computers and programming as a hobbyist and made it the dreariest drudge-work imaginable. Every single routine looked just like this x100, and remember, this was punched cards and coding sheets, no video editors, no cut and paste, ...agghhh! After a couple of summers of that I swore never to use COBOL or do that kind of programming again.

However, fate has a way of not caring. Seven years later and I'm the lead programmer on an Inventory Management system that was ten times the size of those summer projects. And exactly the same kind of code. And in COBOL.

But you know what I found? Once I committed myself to it, it wasn't as bad as I feared. "New" tools and technology helped a lot (video editors, cool!) as did a different attitude and approach on my part. Which meant that I was dedicated to the idea that COBOL or not, I was going to be the best d*mn project lead ever and I was going to be so good at this that I would kick this things @ss, no matter what. (I was still young then :-))

But what really made the difference was, ... (wait for it) ... my Fingers. Yep, my drive to be really, really good at my profession had radically changed my ability to type. I still couldn't type or code quite as fast as I could think it, but I was much closer and you know what? Even the most-boring crap code isn't that bad if you can be done with it as soon as you think of it.

And for this kind of stuff, you shouldn't have to stop and think much, nor should you make many mistakes, so I say your * interesting* goal should be to study yourself and figure out how to push your self faster, and to get through the dull parts as fast as possible so that you can get to the good parts sooner and spend more time on them.

Answer 15

I love the time when I get to do what you call "boring" code. That is because I know clearly what needs to be done and how it works. It's kind of a relaxation time away from complex stuff where you constantly need to think what you are doing!

Answer 16

Sometimes when you write code that is just a repetitive task, e.g transferring a written (hopefully) specification into user interface logic or mapping values. It may feel like you work as carpenter mounting drywalls, another task that requires some skill but is boring and requires no thinking.

But, on the other hand, drywalls was invented to speed up wall construction from older methods. So the same thing applies to software construction. Someone made the specification for how the userinterface logic should work. That specification in written form has to be coded. But as Ozan wrote, use a high level language to generate the code.

Spend a couple of hours to create an excel template where the logic for controlling form widgets is specified. Then write a high level script to convert that excel sheet (exported as CSV or whatever) into working code, then you have offloaded your task of typing code into converting a specification that someone else can create into real code.

Answer 17

Over the years I have used several tools to deal with boring code:

1. Edit macros (The olde worldy mainframe ISPF/Rexx script combo is hard to beat for generating repetative code.)
2. awk/perl/python scripts
3. My current favourite is sqlite and Freemarker. Make up a database of meta data (tables, columns, attribute etc. etc. ). Write a simple Java program to run some SQL and load up your freemarker data model then run your template against it. This takes some setting up but its an extremely powerful substitute for typing.
4. Use a framework with lots of tooling like the Eclipse/Spring/Hibernate combo.
5. Use much higher level languages like Python/Ruby.

Answer 18

Alex P (of TheDailyWTF fame) wrote a great editorial piece related to this question: Programming Sucks! Or At Least, It Ought To:

Just Suck It Up.

It’s not easy to reconcile the fact that the software we write each and every day is, for all intents and purposes, mind-numbingly boring. Magazine subscription management. Medical billing reports. Realty inventory management. This is not the type of software that changes the world. In fact, it probably won’t even put a smile on someone’s face. Its sole purpose is to add to the bottom line by making other workers be more productive.

As unexciting as it may be, it’s our job to do work exclusively to benefit our employer, not for own personal satisfaction. That’s just what it means to be a professional.

(my emphasis)