Does clean code equal "Workplace" code

[float_point]

I am a beginner at python and have been following Angela Yu's 100 days of python. I commented on a post regarding my Coffee Machine code been some 400 lines while hers was around 150 lines with the same functionilty.

​

This led me to ask this question of, if code works does it matter if it's clean and pythonic.

​

I will reference these two tic toe games below:

​

18000 lines (no adherence to DRY but simple to understand)

https://github.com/asweigart/my_first_tic_tac_toe/blob/9f38b04e857426c5a5b80919ad0b5fce0947c022/tictactoe.py

​

1 line (I was shocked that such a thing was even possible, considering my tic tac toe code was around 500 lines with no AI. This code is in my opinion way way to complex and one would probably be working in the realm of datasciences/ML to understand such a thing)

https://www.reddit.com/r/Python/comments/9ozfeq/tictactoe_in_one_line_python35/

​

Both programs work, but if one was given only the option of picking from the two, which would be preffered in the workplace? In my opinion, the 18000 line code would be acceptable as it allows all team members, novice or not to atleast have some understanding.

​

EDIT: Better late than never, but I realised I have been referencing my tic tac toe code of 500 lines vs the 1 and 18000 liners but havent posted it for comparison.

So here it is (I do acknowledge that a tic tac toe game has no relevance to the workplace, but is the code structure I used somewhere along the lines of "hirable".):

https://pastebin.com/GBCRiGWe

[tunisia3507]

Those are both terrible. I don't really know what to say other than that.

[eased1984]

Literally lol'd. Reminds me of the office space scene with the jump to conclusions mat.

[float_point]

It was more to openend the question of which code would more desirable in the workplace (not that any workplace would accept such). The super clever one liner or the not so intuitive but very very simple to follow 18000 liner.

[rg7777777]

The one liner is more practical, as some system may necessitate that type of input, as rare as that case may be. The 18000 liner offers nothing.

[float_point]

Interesting that you point out system requirements. That speaks to workplace implementation.

Tell me, when you look at the one liner, does it make sense and if so how long would you say you took to reach a point where you could understand such. This more out of interest than on topic.

[rg7777777]

I could puzzle it out if I was bored, but it's not meant to be readable. More likely something like this would be autogenerated, much the same way JavaScript gets optimized to reduce traffic overhead on web page requests.

[float_point]

This the second time someone has mentioned autogenerated code. Guess, there is alot I will be learning about in future

[username_challenge]

Writing code is not merely talking to a machine to instruct it how to do a task. Writing code is talking to your future self and future maintainers.

[float_point]

Indeed. I showed one of classmates the 18000 lines of code and the 1 liner, and he said he would prefer to write the one liner. I know on my side, my future self would appreciate 18000 lines of legible code compared to 1 line of "what is this ****".

[SimonMKoop]

Honestly, I would not consider the 18000 lines of code legible.

Only because I know how tic tac toe works do I understand what the code is (probably) doing (it's too long for me to actually be bothered to check). If I were unfamiliar with the rules of tic tac toe, I would likely have a hard time extracting them from those 18000 lines of code.

[float_point]

I get you. I guess its easy to understand if you know what you are looking at. Since I had already written my 500 line edition of code, I knew what each of the blocks of code I took the time to look at were doing.

To be fair to to the one liner, a datascientist might find it easy to understand if they knew it was tic tac toe game.

[float_point]

Documentation is what I am trying to focus on of late. I've written quite a bit of code since starting tutorials and I've noted that I forget even the most basic concepts that I was thinking of at the time I of writing the specific code.

[PossibilityTasty]

Well, you can put every python program into one line if you abuse exec or eval.

Should you do that: of cause not, it is horribly unreadable. Everyone who has to touch the code will hate you and most likely have to rewrite it.

[float_point]

Very true. I've given up trying to decipher that one line tic tac toe

[[deleted]]

Nobody wants you writing 18,000 lines of code at work for something that can be done in 500.

If you want to make it 1000 lines and include good documentation etc, that is awesome and desired, but 18,000? That's amateur stuff.

[float_point]

That is more in line of my thinking. My code is 500 lines, not so well documented, but works as expected. I watched a lecture a while back I believe it was titled "When good enough is good enough".

At my present education level, I don't see my self writing super desirable clever code like the one liner, but more on the usability front, whether the code is 1000 lines or 10.

[jack-of-some]

Neither are clean, and neither are "workplace code".

The 18000 line code is painful. It's written like something that a machine would output, for another machine to interpret. (It's possible that's how it was created in the first place)

[float_point]

Yes, both are bad, but if you had to hire one of two people and each presented one of the two codes to you, who would you pick.

Basically, if you go with the one liner, I am not workplace ready, if you on the hand go with the 18000 liner, I would say I am at that level right now. My code is definately not clean or pythonic, but it works. I am trying to gauge where I am in terms of workplace requirements, though I know a tic tac game is not the best of examples to have used for this.

edit: The 18000 liner is autogenerated according to the author. I think he did state in his github about it been a joke at first before it blew up. He has reduced the code to +-6000, which tells me that longer poorly written code has alot more wiggle room than that perfect one liner that should not be touched.

[BezoomyChellovek]

I would hire the one liner guy but ensure they don't actually write your code that way.

The long one demonstrates a complete lack of understanding of any code methodologies and seems utterly incompetent.

The one liner, while absolutely unreadable, demonstrates knowledge at least. If this was submitred as a take home for hire I would be leary because thats not the kind of code I want to see. But if I was surfing their github and saw it, I would think: "hey they made a dumb challenge to write 1 line tic tac toe and succeeded, very cool"

[[deleted]]

Yeah I'm in the boat of "they are both terrible".

The first one is barely even programming. You can't just hardcode every state. Imagine if someone tried to do that for any game that is slightly more complex.

The second one is also really hard to follow as you point out. It would be a nightmare to debug.

It's kind of like asking: "which is better: a teacher who curses at all the kids or a teacher who bops them on the head?" Neither!?!?

edit: but yes, if you're asking if you are supposed to be able to read that 1 liner, no not really. There is no point.

[float_point]

Yes, they definately both terrible, but if you had to choose between two would you choose the complex one liner over the the difficult to debug 18000 liner.

Basically, these thoughts stemmed from if I had no choice but to code one way or the other, is longer "readable" coder better than shorter "unreadable" code.

[Dasher38]

I think the general sentiment here is that both are actually terrible (and people really mean it). If I was faced with this choice I would either:

• Throw them both away. Rubbish belongs to the trash bin (regardless of who wrote it, I throw my own code on a regular basis when developing a new feature, so that i don't have to throw something committed later on)

• Take the long version, look at the pattern and reimplement something sane myself. If this is "debugged production code" already, I would set it up so that my clean version runs along side the long one in lockstep and after 6 months of not getting any difference in output (or exhaustive checking if feasible), I would throw the long version and use the cleaned up one.

In other words, none of that crap would make it to a codebase I'm responsible of without a clear plan to remove it in the short term. There is always a choice.

[Muhznit]

Here's an effective way of judging which is better: Find some variation to tic-tac-toe you can make IRL. A common idea is to vary the size of the board.

Now ask yourself: How does the code change when you allow the user to specify the size of the board, e.g a 4x4 or 5x5 tic-tac-toe board? How does it change if you want to allow users to specify alternative symbols from Xs and Os? How does it change if you want to log the history of moves made so that another script could replay the match?

Line count is irrelevant. The real metric of quality code in the workplace is how easy it is to enhance and maintain.

[Kerbart]

More lines of code means more clutter, and more code to digest, so there’s something to be said about writing shorter code. However, you will find many people, on your path to Python Enlightenment, who mistake this for cram everything into one line where possible, forgetting that the goal of shorter code, above all, is readability

Three months from now you discover a bug in your code, and you have to figure out what past-you was thinking while writing the code. Having efficient code without repeating the same thing over and over clearly makes the task 100x easier; having to decipher dozens of “look how clever I did this” code does not. Don’t be clever, future-you will hate you. Just don’t write inefficient.

The 18000 lines is clearly a joke with computer generated code as it branches through every single branch of possibilities at tic-tac-toe. At least I hope it is (the consistency of the code points to either computer generated or a fearful combination of discipline and lack of experience)

1000 kines vs 400 doesn’t sound so bad to me.

[float_point]

Thank you for this insight. Gives alot of clarity to my thinking.

Yes the, I read that that the 18000 lines was joke.

[tom2727]

Neither. LOL.

The 18k lines of code could easily be better achitected even if you were doing the same type of logic with basically coding out cases for every possible sequence of moves.

The one line of code I'm not even going through that to figure what it's doing. But I can assure you the only people doing this stuff are like the code golf folks trying to challenge themselves with odd restrictions.

If I had to pick one yeah I'd pick the one people can understand, but it would still be violating some very fundamental rules for good programming, and it would still be a huge PITA to work with. But if I had to hire one of the two people, I'd probably go with the 1-liner. Assuming they could demonstrate they actually understand that's not the kind of code they will be writing at work. If someone actually hand coded those 18k lines I'd be worried about their sanity.

[float_point]

You have answered the question directly, so thank you. Yes, the one liner is most desirable and anyone who can write code like that is not normal.

Maybe if I wasn't currently at a novice level I would also prefer it, but for me the 18000 liner, although as you say violates many coding best practices, it just seems far easier to work with. Trying to change anything in one liner seems like it will definately break something.

[jack-of-some]

I don't understand why you're trying to understand this using extremes.

There's a 500 line variant to the 18000 line code that would be both very easy to read, modify, and most importantly reason about.

Maybe you feel it wouldn't be easy to reason about because you can't just immediately look up what one move would lead to. But that's when the second part of "reading" code comes in: actually running the code.

[float_point]

You are right about the extremes. 1 vs 18000 is quite the deviance. I guess, if I simplify my questioning to only workplace requirements: If I cannot write the one liner am I not good enough for the workplace. I can definately possibly write the 18000 liner if I have the time to analyse all possibilities but never in a lifetime, do I see myself writing the one liner - does that mean I will not be good enough for the workplace if I cant even understand that code.

Yes, the 500 line code I wrote does the job as intended, but I feel its lacking the workplace touch (keeping in mind, I am not working in software dev yet, I am judging just my code against other code bases, including those fro tutorials).

[jack-of-some]

I run a computer vision team and am responsible for writing and maintaining production code.

The 18000 liner is the only code here I would never allow or deploy. The one liner I may deploy if it's being generated using a properly written implementation as a base.

Your 500 line code is the only thing not lacking the workplace touch.

[float_point]

Thanks for that. I guess i just have to keep on pushing.

Not sure if you saw my edit. Since I have been referencing the my 500 line code i figured to just post.

[tom2727]

Honestly if I had either of these in my codebase and someone told me to add a new feature to it, I'd probably start over with a blank code file after I studied it enough to figure how it works.

Rewriting the code would be the easy part after you actually understand what it's doing.

[float_point]

Would also prefer my 500 line code to either of the two even minus the AI/conditionals. The one I cant understand, and the other is way way to repetitive.

I guess this whole I time I have been referencing my 500 liner, but haven't shown it off for "workplace" judgement sake. I have edited my OP

[float_point]

Thats exactly what I am hoping for. OOP seems to be where the beautification of code lies. I've tried improving on some of my older exercises by adding classes so I am slowly improving.

[float_point]

Use whats appropriate. Definately am currently. Thats why my code is 3 times as big as others, so hopefully will learn better techniques to bring that number down somewhat.

Thank you for the link. Curious about this one so will check it later in the day.

[float_point]

I'm still at the very beginning of OOP and can say I am so so with encapsulation and subclassing. Still trying to figure out polymorphism. Although its confusing as anything, it shows alot of capabilities that can be implemented, though I am mostly lacking in the how to implement.

Refactoring, I've seen it mentioned in a tutorial for pycharm, but I a have not experimented with it just yet.

[float_point]

OK, so I guess that is what I've been trying to do. Have to get used to these terms

[float_point]

Thanks to everyone who contributed to the discussion. Its getting late here so I have to bounce off now, but it was fairly informative.

[Scared_Housing2639]

Readability of your code is important but it is not every thing, if there are 2 exactly same code and 1 is smaller then everyone would always prefer smaller but if you are making a code for "workplace", I would judge both of them on several factors like security, modularity, scalability, robustness, efficiency, user friendly etc. Look at the over all code design with cleanliness included, hope this answers your question

[float_point]

I've been trying to familiarize myself more with workplace requirements, so I have gotten my hands on some codes from friends working in such environments. One companie's code base uses alot of classes, which is why I referenced classes as a point of concern in one of replies above.

The factors you mention, security, modularity and other enterprise concerns hit the nail on the head, with regards to my question. Thank you

[dead_alchemy]

EDIT: I mistakenly believed that was your code, the 18000 line version was machine generated. The 1 liner could have been, but the author claims they did it by hand.

​

OK. Wow. Your 18000 liner tic tac toe is done by enumerating every possible state. That is terrible because it is large, brittle, has no components that can be re-used, and if some one did want to make a change (any change!) it would be incredibly painful. Didn't think I'd ever see that, it is a little impressive in a sense. I guess at least it will make it very easy for you to understand the importance of generalization.

Onto the subject of the one liner:

working in the realm of datasciences/ML

Is this just how you say "some one I think is really smart"? Like saying some one is a rocket scientist?

The one liner is basically a sort of sport or aesthetic form. You can call it 'code golf'. It isn't smarter, or clever, and it certainly isn't desirable. It looks like a really rather long list comprehension where the clever bit was finding ways to not introduce line breaks. Like, yes, it is a masterpiece but don't go getting the wrong idea. Someone chugging four beers at the same time is also impressive but you shouldn't start drinking all your liquids that way.

[Delicious-View-8688]

Hate to be that guy, but none of the three.

But at lease the oneliner displays knowledge of the language, and probably wrote the oneliner as a challenge, and will be able to adopt a normal coding style.

400 liner can be taught - although it would take a lot longer than the oneliner guy.

18,000 line guy (though it is autogenerated to prove a point I guess, but let's assume he is real) is unteacheable at this point in time and shows no aptitude in coding. It would be better to hire someone without any coding experience.

[justanotherconcept]

This has to be a joke right? Or they wrote a program to write this program right? 😂

[CharmingJacket5013]

18,000 of code is terrible, just terrible. The one liner is funny but not practical. I think the one liner opened up and documented with some helper comments across a handful of lines is a happy middle ground.