Is it acceptable to use tricks to save programmer when putting data in your code?

Question

Example: It's really annoying to type a list of strings in python:

["January", "February", "March", "April", ...]

I often do something like this to save me having to type quotation marks all over the place:

"January February March April May June July August ...".split()

Those took the same amount of time, and I got 2x the # of months typed in. Another example:

[('a', '9'), ('4', '3'), ('z', 'x')...]

instead of:

map(tuple, "a9 43 zx".split())

which took much less time.

Answer 1

I would find this acceptable, if a bit lazy, as long as what is being done isn't too performance critical. You could always go back and optimize it if you need more speed.

Answer 2

Code is usually read many times, and it is written only once.
Saving writing time at the expense of readability is not usually a good choice, unless you are doing some throw-away code.

The second version is less explicit, and you need some time to understand what the code is doing. And we are simply talking about variable instantiation, not about algorithms!

Answer 3

In general, I think this is a bad idea. The first example isn't SO bad (it's sort of a substitute for python's lack of qw), but the second is much more difficult to understand. In particular, I think this sort of thing is very unpythonic, and certainly not appropriate when writing Python code, at any rate. Code readability is much more important than saving a little time writing the code. If you really have THAT much data to hardcode, write a script to generate it for you.

Answer 4

How often do you really need to type ["January", "February"... etc]?

Granted your approach might save you time but why add complexity to your code for no good reason other than you are a bit lazy?

If you really do have to type it that often... Copy-Paste!

Answer 5

...I often do something like this to save me having to type quotation marks all over the place...

I think such a thing should be done only once per program. If you do the same "all over the place" then it doesn't matter which one do you use, you're creating a monster.

Such declaration should be written only ONCE for all the code.

Answer 6

It's a reasonable thing to do for data that you don't expect to change, such as months or days of the weeks. It's also reasonable to do this while mocking up or stubbing out interactions with files or databases, because it isolates your code for testing. However, this isn't a good long-term solution for production code, nor does it really save you much time. Anything big enough to allow big time-savings is big enough to require storing data someplace else, like a separate file o a database.

Answer 7

In production code, do it the right way. In test code, as long as this idiom shows up more than once or twice, I think this is acceptable. If, in test code, this situation shows up once or twice, do it the right way.

Answer 8

A good text editor can make these things a non-issue. For example, I can type the following line in my code:

print `"January February March April May June July August September October November December".split()`

And then using the key sequence V:!python<ENTER> I can run the line through the python interpreter, and the output is the following:

['January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December']

I'm using Vim for my example, but I'm sure this is just as easy with Emacs, TextMate, etc.

Answer 9

I don't think that type of thing should be in the source.

If I were you, I'd have Python evaluate the respective second versions and then paste the results into my source code.

Answer 10

In a reasonably smart editor you could:

1. Select the lines of interest,
2. insert the replacement (<space> by "<space>" for the 1st ex.),
3. check selected lines checkbox,
4. click replace all,
5. bam.. your done.

Readable and easy to type... respect the power of the editor!

Answer 11

I think putting statements like

"January February March April May June July August ...".split()

at module global level is fine. This way it is only executed once during import. I even sometimes use it in non-performance critical functions because of the reduced line noise.

On a sidenote i think that Python Interpreters could be made to execute the "split()" at compile-time which would eradicate the method-call overhead. Reason being that a string is a builtin literal and Python does not allow to add/override methods on the very base string type so the compiler can know that "".split() can only refer to one specific method.

Answer 12

I all but swear by Steve McConnell's Code Complete: one of the core insights is that bad programmers write code in order to get computers to do something, period, while good programmers write first to write code that people can understand and only second to get the computer to do things.

(Having code that is written without readability as a major concern is like trying to find things in a closet or filing cabinet where people just cram stuff in without any thought to making something you can navigate and find things in.)

I think you could profit a lot from reading Code Complete; I know I did.

Answer 13

your quick and clever methods while nice, take more time to read which is not good. Readability comes first always.