abusing comprehensions for one line loops

[Skaperen]

how acceptable is it to do this:

    [print(x)for x in foo]

instead of this:

    for x in foo:
        print(x)

now that my thinking includes readily throwing away data which an optimizing compiler can avoid.

[stranac]

Not acceptable at all.

Creating a list for side-effects makes no sense, and it's ugly.
Use a regular loop, lines are free.

[Skaperen]

thank you for input. i will avoid those.

the reason i'm always looking for ways to reduce lines is to see more code in my finite size screen display. my current project is a command to download and process specific cloud data and it is just about to reach 700 lines. yes, there are some empty lines where spacing helps readability. my screen only has 34 rows, now that i switched to a larger font.

[ndc85430]

Dan North has used the phrase "software that fits in your head" in one of his talks and I do think there is value in having files that can (mostly) fit on the screen at once. I think that trying to decrease the line count by condensing things in the way you're suggesting isn't going to provide much value, though. Instead, you'd be better off breaking your program down into more, smaller, more focused modules which would just be a lot easier to maintain.

[Skaperen]

if i have to jump around a lot to see the big picture, i haven't gained by going small. but identifying cases where some code can be reusable standing on its own, then that part can be maintained on its own.

[ndc85430]

The point is though that that structuring can help you see the big picture. I work on quite a large project (albeit in Scala, but that's really irrelevant here) and the team has put a lot of effort into the way we organise the codebase. I believe those efforts have paid off, because it's quite easy to find things when you need to make a change and you aren't bothered by extraneous detail when you're in a particular place.

If you haven't read Bob Martin's Clean Code, I highly recommend it. The ideas I mention are, in my mind, similar to those in the book but on a larger scale (e.g. the "step down" rule he mentions is at the level of a function).

[Skaperen]

i can see the overall code easier if it fits on my 34 (35, but the bottom line is hard to make use of) line screen. when some part of the logic gets moved to be inside a function located far far away, then all i can see is the call to it. if the call itself makes sense then i can still see the big picture. but if it doesn't, then i can no longer see the big picture. often, the block of code in a loop has "side effects" if it were made into a function.

but i have already agreed not to use a comprehension, purposelessly. that is if it throws away what it just created, it had no true purpose being a comprehension. OTOH, using that value for something would generally justify it.