There's been a lot of debate down here about the definition of "clever" and whether or not mine is the right one. That's cool, of course, especially since the term tends to be used differently between British, American, and other dialects of English. But, if you watch the video, I think (hope) it's clear what definition I'm using. I'm clearly not saying, "don't write intelligent code". I am saying, "stop showing off, it's usually not worth the cost."
The title should've been "Don't write syntactically clever code". All of your progress in computer science is because there were clever people with clever solutions, but as long as you can represent that clever solution in the simplest and most understandable way, there's nothing wrong with a clever solution.
Not really - you're talking about solution design, not code itself. Code is the stream of tokens that make that solution, and there are dozens of ways to implement the same solutions with different streams of tokens.
Clever code is great if you read it and immediately think "Oh thats clever", but clever code rarely ever is easily understandable. Thats why you should avoid it. Keep it for the places where it matters because of Performance. That is why I code in Python. If there is ever some place in my program that NEEDS clever code, someone else will write that in C and put it in a library. And it is fine that they need a week for that hundred lines of code. Meanwhile I am quite happy writing neatly formated easy to understand code which could be more optimized, but who cares its Python. We choose Python, because in a year when that project is on someone elses desk, they won't have a hard time understanding what is happening in my code.
This made me think of a really interesting algorithm used in Quake III to do an (approximate) inverse square root quickly. It is essentially unreadable, but arguably ingenious. I don't have nearly enough skills to talk about how it works while understanding what I'm talking about, but I think this video ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-p8u_k2LIZyo.html (the one I learned about it from) did it very aptly.
@@vari1535 Continuing on HiltownJoe's response, a clever CPU engineer will have implemented a faster inverse square root in hardware. So while the Quake III implementation is very cool, impressive and satisfying, it is not fast by today's standards, and it is (as you said) essentially unreadable. I think the earlier commenters here hit the nail on the head: find a simple, readable and elegant way to solve the problem, and use clever libraries or isolated clever functions where performance is important.
@@Takyodor2 you would be correct in thinking some CPU designer would add a hardware implementation for fast inverse square root, as that's exactly what Intel did. Though it's part of AVX512 so it's relatively new and it's likely that AMD will never support it. Though also because it's part of AVX512 that means it can perform it on 16 single precision floats at the same time. If you wrote some C code that would try to calculate invsqrt on one or more floats in the most obvious way possible -- using sqrt from standard library and inverting it -- that would allow the compiler to turn your code into what you really want: that single AVX instruction. If you're not compiling for AVX512 it could still turn it into a couple of singular AVX instructions. But if it can't recognize what you're trying to do, it won't be able to optimize it. If you write your own invsqrt function that does it the quake III way, it won't necessarily be able to recognize that (especially if you use a slightly different constant in it), so it'll just compile it into a much slower implementation that calls a function on every value as opposed to doing the whole thing in at most a couple of instructions. So this is _exactly_ a situation where doing it the obvious will likely achieve the best results. I have a personal belief that "only assembly code that's 75% comments should be clever." At the very least, anyone who wants to write clever code should have a decent understand of assembly and how the compiler optimizes code. And make it like 75% comments.
I love this particular quote of Dijkstra that carries much of the same message: “The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.”
I agree, though I've had the experience where a coworker couldn't read NOT logic, so I got complaints if I ever just did "!someVariable" in an if statement, long ass ternaries that were a bit of a mess were fine but not those damn NOTs
@@Sweenus987 welp, that's another problem called lack of skill. As ! means negation in many popular languages, I'd say the coworker was very junior. To the original commenter: I'd rephrase it to "Making your code readable and maintainable is a must; making it smart is a nice to have".
Important to note that you can also write high level "clever code" (e.g. turning a 300 line extremely readable script with duplicated code into a 1000 line unreadable mess with no duplicated code)
Who cares about readability Sonar said second one is better due to no duplication and less cognitive complexity. You better do what management want and keep those sonar report clean!
"An idiot admires complexity, a genius admires simplicity" Say what you want about Terry Davis' people skills, he definitely knew what he was talking about in regards to computing.
I have been coding C since 78 (self taught from K&R first edition). I totally agree. It takes time to get a brilliant idea. It takes more time to get the idea a second time if you haven't looked at the code in a couple of years. Simple is elegant and better. Thanks.
A couple of days ago I had a "brilliant idea" to solve a problem, yesterday, I had to refactor the code due to bugs elsewhere, it was an easy process except for that brilliant piece of code.
I am just a complete beginner to computer programming, and I have a question about something has been said in that comment which is: "It takes more time to get the idea a second time if you haven't looked at the code in a couple of years." I do know that you can write comments in the code section; my question is: isn't that a perfect solution for such a problem?! I mean knowing why exactly you've had written the code the way you have, and then there would be no problem at all debugging it, or whatever. And, please, do excuse me if I'm wrong 'cause I'm a newbie!
As Jacob said... Even if debugging was only 5% harder than writing the code, Kernighan would still be right. In any case, it's a brilliantly insightful quote.
Either way, it's assuming that you can apply some mathematic formula to 'cleverness', *and* that people ever really hit their maximum possible cleverness. Those are some big assumptions.
Absolutely! I work on a code base that lives for 20 yrs and had a decent turnover of developers. I ALWAYS design and code to the common denominator. Maintenance is more important than clever every time.
I've even gone so far as to take the time to rewrite/redesign big chunks of code to get rid of the "clever" that other people put in there in the past, because no one else wanted to touch/maintain it.
@@paherbst524 Thank you. I've only worked as a software developer for less than three years, but my mindset has shifted significantly from "cool, clever code, this programmer must be so smart!" (in school) to "nice, my colleagues removed that garbage 'clever code' to make it easier to maintain in the long term.". People like you make this job bearable!
@@stevecarter8810 really simple example: let's say that you are making a program that contains a list of cars. each car has several properties. everyone on your team knows how to work with lists, but not everyone on your team knows how to use Classes. the result is that you end up creating several lists. one list for each property. now you have to start messing around with index positions to tie the properties of the same car together across list, and having to make sure that each list is in the same order and has the same length. another example: let's say that not everyone on your team knows how to use Exceptions. you end up with the arrow anti-pattern cluttering everything, because most of the code will be dealing with error handling. not to mention passing custom error codes up the call stack. if only these were examples i never encountered. the point is: the common denominator could be lacking some of the very basics. at some point you have to say, that they just need to learn these concepts. so as with most "rules", there are no absolutes
This is one of my pet peeves. "Clever" code usually means harder to understand and harder to maintain code. Keep things simple and easy to understand. If you do write "clever" code, at least document the cleverness so the rest of us get the joke.
@@donjindra they certainly should document the WHAT. And with that in place nobody cares HOW it does it, the key is that it continues to do it. With full test coverage, the next guy can try things and find out whether they broke it. "Clever" code should always be fully covered by clear unit tests.
@@stevecarter8810 If one doesn't care how things are done then he isn't thinking like a software engineer. He isn't thinking about maintainability or performance.
i.e: in this example "over"engineering would be using custom string objects, which store the length of the string separately and then having a string copy implementation based on memcpy, which is much faster than a loop. it can make sense to do that though.
The principle of Occam's razor - "when you hear hooves, you imagine horse, not a zebra". Find a solution, implement the first good solution that comes to mind and is appliable. And I cannot stress this enough - COMMENT IT. The general workflow of your solution and each step that might raise questions
To be honest this advice is not that useful. The problem is that code readability is very subjective. Secondly, code can be hacky and readable or once. For example we can wrap that one liner in a method with proper commentary.
Maybe I'm just a bit naive, but it never occurred to me to make my code anything *other* than as transparent and as easy to follow as possible (partly for my own benefit...). If you've got a good overall idea for a problem solution, *_that's_* what should "impress", not whether you can express it in impenetrable code or not.
I agree, clever code is code that is simple and extensible. It's not code that is verbose and complicated. Self documenting code is after all the only thing I do, since writing docs is boring.
Depends. In my CS class we had the wonderful task to find the prime number decomposition for a given integer x without using a defined array of prime numbers. In theory, it is easy. Just go up every number and use modulo. But if you have to take that code running FAST, then you have to do it a little bit smarter. Was a pain, but I got it decently fast
@@docjoules4738 That's the "beauty" of prime numbers...they _are_ easy ... *in principle...!* I'm certainly no mathematician, but I seem to think finding prime factors is an intrinsically difficult (ie, time consuming) process. I seem to have a vague recollection of a process called the "Sieve of Eratosthenes" (which I never fully understood...) which was a somewhat more sophisticated approach than simply taking the modulo each time.
I feel so attacked right now lol. I'm a junior and I've been spending like 5 times longer than necessary trying to write "clever" code so my coworkers will be impressed and not think I'm a fraud :< that's a great advice
Hey, showing willingness toward learning when others clearly teach from their own experience is most likely one of the most important steps to becoming a great programmer. You’re probably on the right track 👍
Imo this is the key. I think it's a fallacy whereby you unconsciously go "hmm, while I was learning, I stared uncomprehending at code for ages before having an 'aha' moment. When my code does that to others, I will be pro"
It's my 13nd year in the field as a professional. I code especially like a "noob" on purpose, down to putting each loops in their own functions. Why ? Simply because it makes it way easier to read and lend itself for reuse. Another one is voluntarily duplicating code. The reason is that early factoring can lead to sub-optimal solutions as you may factorize incorrectly and will tend to work around what you factorized in the first place. And one trick most senior developer ignore: assumptions! A lot of language have a keyword to code assumption into the program. In Java, it's "assert". Those are much better than a comment as that code can be enabled with a flag when launching the program. Which means assumptions will be checked during testing. On top of that, it document preconditions, post-conditions and fixed points to fellow developers who have no clue about them! (Good idea to look up those terms and the equivalent in the language you use)
Another Kernighan quote: "Although this may seem cryptic at first sight, the notational convenience is considerable, and the idiom should be mastered, because you will see it frequently in C programs." from K&R2 page 106, referring to the line of code "while (*s++ = *t++) ;"
indeed, common language is important. C and Go have lots of these, but they can also be find in higher level concepts. Sometimes it's better to use something that's less descriptive on first sight because everyone who worked with this language a bit would immediately be able to recognize it.
The problem with this advice is that oftentimes it encourages programmers to avoid writing code that is less bug-prone in favor of making it more debuggable. We want to avoid having to debug the code in the first place, even if that requires more advanced coding techniques that less experienced programmers do not understand. It’s like designing a safe airplane, you want to do everything you can to make it not crash in the first place, not concentrate on how to make crashes more survivable. Instead, add a unit-test to make it easier for other programmers to prove the correctness of the code and to understand how it works.
This is an interesting counter argument. For certain parts of the code, you might never have to touch it ever. However, a huge part of any project is prone to future changes. Say, designing an airplane’s engine, it is possible to make the safest, most reliable engine anyone can ever dream of, but that would most definitely be economically unfeasable.
Also strict requirements (for example performance) sometimes requires somewhat obscure looking code. You might try to make it more verbose, but it just gets worse. In short, very core areas of your tech often necessarily require expertise to enter.
@@twinkytwinklier4047 Yes, adaptability is important but also tends to require more advanced coding techniques or language features. Debuggability should not be the primary goal when writing code...it is the assumption that the code is not correct and will have to be fixed later. Correctness, efficiency, adaptability, portability, etc. are always more important than debuggability.
@@gtdcoder Come to think of it that makes sense to strive for efficiency or adaptability. But most of the time the code you’re writing is untested (new features, upgrades, bugfix, etc) as such shouldn’t you plan for debuging initially? Once the approach has proven itself to be working, you can then optimize it & clean it.
@@twinkytwinklier4047 The moment you begin optimizing the tested code it becomes untested code again, you might as well go straight for the optimal solution while keeping some asserts around until they are proven to be unnecessary
The problem with while(*d++ = *s++); is that it's modifying both d and s - so you won't end up with both pointers pointing at the beginning of the string, but with both pointers at the end of the string. That would be enough reason for me to avoid it.
And copying memory is often faster using vector instructions. This would copy one byte, one int, etc. at a time. The "clever" solution will end up being slower most of the time, with its best case being just as fast.
@@sontapaa11jokulainen94 in this case, I'm referring to instructions which work on multiple pieces of data simultaneously. So instead of saying "copy A to X, B to Y, C to Z, D to W" you can say "Copy A B C D to X Y Z W". They aren't without drawbacks, and it's seldom a drop-in replacement. But there can be a large speedup when the task is right.
Who decides what is "clever?" Some programmers do the bare minimum growth after landing thier job, while others spend every waking moment trying to improve their skill. What's clever to one person is dead simple to another.
This is one of the most important aspects...Not all of the team members are gifted with the same iq.I have seen teammates who flex their iq with clever code and end up wasting not only their time about the fellow teammate's time too while debugging
IQ is completely unrelated to writing clever code. You can have 160 IQ and still be unable to figure out code. Not writing confusing code is supposed to be a precaution. If someone writes such code in your team, don't be offended like a little child, instead show them this video.
It’s not about intelligence, anyone can go out their way to learn all the niche compiler behaviours and operator order rules and hardware side effects to write code that works (at least for the cases you bother to test!) but that’s not intelligence: that’s at best a coding test, and at worst a case of obfuscation. There are very very very few times where obfuscated code is good. Real intelligence would be writing factorised, organised, readable code that performs fast and safely.
@@arnitdo IQ is related to making novel connections which is why we see that smarter mathematicians, for example, make more innovative proofs because they are able to tie in different areas into a coherent solution better
Also, stuff like "strcpy( d, s )" has far fewer moving parts, thus fewer opportunities to make an error (you can only get either the function name, or the parameter names wrong). I know it's just an example, the only thing still lacking in the strcpy version is better clarity in the parameter names. ( I know d is destination, and s is source, but we shouldn't write code like they are telegrams charging per letter )
I think the "anti-clever" trend is dangerous in the long run as programmers more and more often prioritize readability above performance and correctness. If there are parts of code that are hard to understand, you can always write some comments or divide your implementation into smaller chunks (functions or macros). Duplication of code to improve readability is not a good idea as well. Maintainability and cleverness are not contradictory to each other.
As long as the code is performant enough, there is no need to add extra performance with some cool hacky code that is hard to maintain and read. Algorithmic optimization is far more important that executing like 3 more syscalls.
With this way of thinking, every benefit that comes from hardware speed will be eaten by programmers who write "just enough" code. It is hard to imagine why you cannot comment parts of code that are difficult to understand by beginners. I say "beginners" because an ability to read messy code is a trait of a good programmer. An ability to write clean code is his trait too, but let's keep priorities straight.
if your clever code is well documented, correct and debuggable, nobody will ever get rid of it. If all your clever code do is to save 2 cpu cycles, there is no point in spending hundred of humans cycles to maintain it
If this is really the case, I am all right with it. Unfortunately, I had situations in my worklife, when the code which was easy to understand by a human, but did not pass all tests, was merged into the master branch in favor of the code that was algorithmically correct and passed the tests, but was not "intuitive enough". Therefore I think this "non-clever code" movement is rather a way to degrade software quality as it causes misconceptions.
The double-standard. I keep hearing this kind of feel-good engineering trite on YT, HN, etc. Meanwhile in my career, not once have I seen any of these 'great ideas' put into practice. Instead I see 'currying' and 'indirection hell', time-bomb code, code that was purposefully made slow, etc.
Yes, same. I'm actively trying to fix this at my current employer but tbh I feel like just wanting to code on my own projects so I don't have to deal with badly maintained code "because we don't have the time to build it well"
It's also pain to re-test. And when dealing with legacy codes that don't have documentation or test cases, it's hell. You can be blamed for anything and everything that has got something to do with this code (even though it makes no sense)
Sometimes cleverness is mathematical and efficient. If I can reduce a Boolean or algebraic expression, I’m going to even if it looks absurd. It’s just I’m going to document the derivation to make sure the strange expression is understood. These reductions may often be easier to read as they can be magnitudes less verbose, but harder to understand conceptually unless the derivation is shown.
Hallelujah! In recent weeks, I have watched several videos extolling the benefits of avoiding if-then-else statements. That’s fine when such a statement is simple. But complex ones? Are you mad? Are you intent on driving your fellow coders mad? I’d prefer an older version that is easier to read over a fancy version that’s hard to follow and therefore hard to maintain even at the expense of a few clock cycles. So, hallelujah!
Agree. In a past career I was tasked with porting a bunch of 3D graphics code from Unix to 32-bit DOS. Ran into one line of code in one program that was causing run time issues. It took several hours to unwind that one line code (uncommented of course)and split it up until I could figure out what it was trying to do. I recall it was some sort of RGBA pixel bit banging function. I finally split it up into a number of single operation lines of code with the intention of sticking printfs in between each line of code to see what was going on. But never got that far, because once the code was all separated out, it worked as designed. I think the root cause was that while the code compiled and ran fine on the Unix compiler and CPU it was originally written for, that same source caused either the 32-bit DOS compiler or the x86 CPU architecture to choke. There were no warnings or errors generated, it's just that incorrect pixels were showing up on the display.
"Simple and straight forward is nearly always better" is close to and understatement :) For me, a grug brained developer, complexity spirit demon, IS worse than t-rex...
When I saw the title of your video, I just knew you were going to use that string copy example. I don't disagree about unnecessary cleverness, but that particular example is very much a standard C idiom, which is even in K&R. I think that if you're genuinely unfamiliar with that idiom, you really shouldn't be maintaining a C codebase, because you don't understand the language well enough to prevent making a mess somewhere else. That said, Python's comprehension expressions are a standard part of the language, and are intended to be used as such. They can be painfully difficult to understand, especially when they involve nested loops. I guess "There should be one -- and preferably only one -- obvious way to do it." fell by the wayside at some point.
strcpy does the same and it's not slower whenever it matters, so even if while(*p++ = *q++); is an idiom, it's a stupid one. strcpy is usually a compiler intrinsic.
Me working on embedded stuff: *Separates C application from single 4000 loc .c file to 2 source files* My Electrical Engineers coworkers: *Stop being clever with your code*
Same with using one letter variable names, we don't have the restrictions of old where we had to do that anymore. PLEASE use proper naming for variables, it means debugging is so much faster if I know that I can search for a variable called variablename vs searching for i or x, plus it makes reading the code quicker.
I'm just cognizant of when I write something that might be confusing to follow, so I leave a comment where it's due. In fact, documenting your code is THE counterargument to this, with the downside being that good documentation can make the coding take twice as long.
There are times when clever code is warranted, but the comment explaining both what it does and why that particular syntax was chosen, needs to be proportional to the cleverness. Especially with modern hardware which gets speed from clever trickery rather than blunt clock speeds, two approaches may output the same final number but one could be very friendly to caching, the branch predictor, and parallelism while the other is not and this can mean 2 orders of magnitude difference in execution efficiency. Not relevent for a function that runs 0.1% of the execution time or dominated by idle states, but very relevent for a function that makes up 10% or more of the execution time. (And for the big hardware even a 1% improvement can mean $100s of dollars per day of runtime just in electricity cost let alone amortized hardware capital.)
Great to bring this up. That kind of thing is the difference between being a "hack" and a professional developer. Good code should be elegant and readable, not contain a lot of subterfuge. I've seen high-schoolers just learning C/C++ that thought they were being cute with weird or vulgar variable names and stuff like that. It's great to enjoy yourself programming, but go to the next level and develop some awesome, professional level code if you really want to impress.
But... "clever code" isnt obtuse code, or long ass codes. Clever code is absolutely a good thing, if it is clean and simple, right? Saying no to make clever things is kinda stupid, especially in the tech department. everyone gotta keep up or we will keep having codes style from 80's (look at AAA games)
@@Landofahero Did you watch the video? "clever" in the case being discussed is used ironically here. His point is that the code is not really clever or valuable in a meaningful way to make the code faster or better. It is only more unreadable and a bad practice overall to write code that way. So the point is not to write code in that way and make it hard to troubleshoot or read. Real clever code is lean and elegant and should not be hard to read. Good coding knows no decade. Beautifully written code is ageless regardless if it was written in 1980's or tomorrow. And lousy code is also lousy code regardless of when it was written.
@@rexjuggler19 Yet the title of the vid is here, and without "". Kinda of a "bad code", isnt it? Yes Ive watched the video, rest assured. I am unsure about code being ageless, Im not a programmer, I dare not to speak about it, I just know a thing or two, and a few people. Usually they have hard times going from 1 type to another, or 1 engine to another due to codes...
The coder we hire back time and again is the one who communicates efficiently to ensure they understand the change and we understand the tradeoffs, makes the change, tests it and tests the tests, and reports back with anything that didn't turn out as expected, or whee code clarity might have suffered
You mean kernel developers or module writers shouldn’t use clever code what? Your example doesn’t make sense it could be that strcpy isn’t available to be used next thing you know you’ll be complaining because someone sprinkled in some assembly code. If you call yourself a programmer you should try to understand how a line of code works.
if you cannot write a unit test for your function with at least 80% coverage then the function is too complicated and the structure needs to be redesigned
Your first example - yeah no. That was not "clever" code but the only way to do that operation cause the libraries did not exist. Also nowadays the first version could do a lot more than the second one - iterators over lists for example. And i have seen similar cases in our own code were we needed this (this involved type-conversions).
Absolutely 🙏 Also: talking of debugging, the stacktrace is very important. Some patterns like DSLs and fluent build pattern tend to obfuscate the stack. When you use them, think of the poor sausage who needs to debug it in two years. By using parallel programming and coroutines/async methods (which is nice and necessary), it’s often already hard/impossible to read.
Spot on. I try to avoid language specific syntaxes where possible, keep it clean and simple that way it's readable, debugable and portable to other languages easier
People who write: a = a >> 1; instead of: a = a / 2 And my reaction to them: YOU FOOOOL THE COMPILER ALREADY PERFORMS THAT OPTIMIZATION EVEN WITH -O0 😑😑😑
I disagree. The hardest-to-read code I've run into was because whoever wrote it did not attempt to be even slightly clever, but instead simply fiddled with it until it worked, got a new requirement, fiddled more, and continued this until there were hundreds or thousands of lines of complicated (and often redundant) if statements that altogether worked through what seems to have been trial and error.
Really good point! A somewhat related consideration: I often have to program in 2 or 3 languages in a day. Worse, I'm never 100% sure I won't need to port code from one language to another. For these reasons I try not to use clever language-specific features when I can avoid them. Makes it easier to switch between languages, both mentally and if I do have to port stuff.
@@HappyCheeryChap So, there's no hard and fast rules about when I do it, and it all depends on a bunch of factors (how useful the language feature is, how well I understand it, the purpose and likely future of the code, how much time pressure I'm under, etc.) But it's relatively easy to port between C#, C++, Java, and Javascript if you stick to a common subset of features and syntax when possible. Even converting Python to one of those, you can speed stuff up by using parantheses around expressions, and semicolon line terminators where they're not needed (in Python). I'll try to avoid using multiple inheritance because some languages don't have that (and most of the time there's a better way of doing things). Same with operator overloading, using LINQ too heavily in C#/.NET, things like that. I find most system APIs have reasonably good equivalents in different languages, though sometimes I've had to write wrappers to keep things in line without making a tonne of changes throughout the codebase. There's languages like PHP and R that I have to use which are a bit harder to deal with - but they're a lot more domain-specific anyway. I also wouldn't consider myself an expert in any of the languages mentioned - most of them I use because I have to in order to get paid, not by choice :)
@@MisterPotatoHands This is OK for your own private code, but for example putting semicolons into Python effectively means you won't be able to hire a python dev or make the project open source. I'm also working in like 5 different programming languages at the same time (Python, Rust, Typescript, Go, Vex which is like C) and I make heavy use of the features but then again I never need to port anything between them as they all have their specific roles :)
@@Luxalpa Oh, absolutely! The whole team dev and open source requirements is one of the factors I need to take into account. I've been working as a solo dev for so long on non-open source projects, that it's not been a concern... but I really do worry how well I'd fit into a team environment these days, or contribute to open-source, which is a damn shame. One factor I didn't mention is the cognitive issues I have with learning each language deeply: when I've done so in the past it's too easy for me to forget which features belong to which language, and it all gets a bit confusing and slows me down. I don't think that limitation would affect everyone equally, though. But, yeah, I will say from experience that porting a big framework between languages is a lot easier/faster if you don't rely too heavily on language-specific features.
I found this to be true when using RxJS. I was in this mode trying to combine everything into one single variable and that equated to alot of complex RxJS. I found it much harder to debug and although it doesn't look as "good" to have 4 separate variables in the long run it makes mine and everyone's like easier
I think I use about the same number of variables in Rx code as in non-Rx code. I just really love to name things. It helps me split up the task into tiny bite-sized chunks that I can tackle one after the other.
When compared to developer time, compute time is practically free. So unless your code loops millions of times don't optimize it completely. Maintainable code can always be converted to fast code, but fast code can't always be converted to maintainable code.
That depends on project you work on. Your personal website? Hell, call a factorial of random number each time any function gets called, noone cares. Actual commercial project? Control system? I've worked briefly on energetics distribution system and execution times were one of criteria of the product. The compute time is not free, you don't have to count time and memory complexity for every loop you use but you should have an idea of how intensive your code actually is. And you might be better off implementing more complex solution using two arrays and one for loop than simple solution using 3 nested for loops.
This seriously bugs me. I do 50/50 work/study for my bachelor's degree and learned to do things properly at work because we have mandatory code reviews for everything a student does. If I ever tried to write clever code, I would get the aftermath about a day later. But the things my fellow students write are simply astonishing. Sometimes I think they never debugged anything. Seeing this miserable code made me think differently about the whole code review process and the strict conventions we have at work.
what do you mean by clever code, if I optimized the code so it runs several times faster than before but also becomes less readable, should I avoid doing that? My suggestion is, if there are significant benefits of writing "clever" code, then write it, and explain it in comments. But don't write unreadable "clever" code just to show off.
Yes, adopt even "smarter" code and rely on hardware advancements to make it perform. The web developer's motto for the last 10-15 years. "Have you taken your 2GB of dependencies? Have you eaten all of your 350 funciton calls to perform simple tasks? Good boy." I know the video's spirit is not condoning that, but that is the target audience that will praise THE FUCK out of it.
If you are innovating you may have to write clever stuff all the time because there may not be another way to do it. If you are working at Tesla and self driving for example. But if you are working at tesla you are probably among the 1000 smartest people in the world.
Code that "sticks around", such as code at the core of some engine or kernel, should generally be both fast, correct, and untouched. That's what sticking around means. With modern formal verification and superoptimization, one can get essentially optimal implementations of code that you also know works. Such implementations are basically impossible to understand and often rely heavily on embedded assembly. And that's fine since it should only have to be designed once. Maybe again a decade later when you want to move onto a completely new system. Why are you trying to make code that's not supposed to be modified easier to modify? That does have its costs and by definition has no practical benefit. It's possible to just design something that works by applying proper engineering principles. You can't get quality work by hacking, but it seems like every programmer thinks there are no alternatives.
Oh man you are so right. Especially self-declared coding geniuses (usually with 10+ years of experience) like to do this, making this kind of people not only worthless, but highly dangerous to any development project simply because the code can't be maintained. Next to this, these people (in my experience) also like to have endless discussions about, why their view of abstraction/object model is the only reasonable one, and they love to waste project time on optimizing code, that isn't the bottleneck. My advise: if you've got such a coder (and any PM will rather sooner than later stumble across objects like these), either directly fire him/her or don't let him/her not write a single loc, but rather write the documentation and prepare the test data and test cases for release testing.
I had a coworker like this, senior architect / backend developer. His code was bulletproof - noone could ever maintain it, the only option was rewriting everything after him. The joke is, he was valued and paid the most because he was "essential" as his replacement would unleash his code demons.
You could also wrap clever "but hard to read" or messy solutions in a function that abstracts away the BS. Wrap that while loop in an inline function called strcpy_clever and call it a day. You could also use the safe versions of strcpy.
if you write code that only you can understand, then you are stuck with it and can't move on to other stuff. if you write code that even the newest junior can work with, you are cleared to do the more important things. this is also where verbocity comes into play. write comments, describe which design patterns you use (CRTP is great once you know to look for it, but if you don't know it's there, then it's a mess). keep the DRY principle, and have everything in a function of it's own with a clear name. take the very clever while loop and put it in a function that takes the source and the destination strings. name the function stringcopy. call it from the driver code. now that you don't have to look at the clever function, replace it with strcpy (better yet, strncpy), and put the very clever function on your perssonal github.
Both strcpy and strncpy can lead to buffer overflows. Especially strncpy will produce unterminated strings. It was intended for the historic unix disk directory format with max 14 character file names, ending at \0 or byte 14, whatever comes first. A safer function, but not efficient, is sprintf(dest,"%.*s",sizeof dest-1,src).
In some toxic cases, writing simpler code means that you are expendable to the company you are working for. Writing code only you can maintain provides you with job security until you can bail form said toxic environment.
@@PathOfDamn I know of a case where another engineer wrote unmaintainable code. When management found out, they started a project to replace the internal software with an external standard product. A few developers were kept for maintenance, that one lost his job. Guideline for managers: as soon as you are dependent on a single person or small group of irreplaceable ones, get rid of them as fast as possible.
@@Hauketal That's two really different type of management I guess, I'm glad the case where you know of the management proactively try to ensure that the team does things right. Then again, if your example's management is that proactive, then I doubt it is toxic as it was in my example.
if i have clever or complicated code i usually put it in a seperate method so the method name explains what it does and makes it much more intuitive at the place where the method is called. When debugging i then only have to check the code arround the call, or the method that i already know what does, and i wont confuse them because they are clutted together in the same method.
From my experience it depends on the size of the software. Writing code scales somewhat linearly, while debugging is more exponential in nature with project size. Something like a hello world is going to be easier to debug than it is to write as you don't even need to run it to tell what it does; whereas a massive project with thousands of lines of code is going to be a real pain if not maintained correctly. And even if you understand the smart line of code you wrote, you don't know if it will be you or someone else in 1,2,5 years time trying to support that code and trying to work out what it does.
It depends how "clever". If it doesn't make a significant improvement, then it's bad. Whereas some proper clever code can be fundamental. Like Quake III's fast inverse square root algorithm. Simply being complicated doesn't make it bad. If you really need speed, you gotta get creative. Things can be complicated. Math functions like sin,cos,log,square root,etc are complicated, but doesn't mean we can't trust that which we don't understand.
Also, clever code was a necessary evil when people had 64 kb of RAM to work with. These days, you could fit the whole Library of Alexandria under 64 Gb. You won't ever write 64 Gb of text in your life unless your last name is Asimov and the first is Isaac.
I think the cleverest code I have ever written was passing a function pointer as void pointer, then casting it back when calling it. But this was mostly because I wanted to test different comparison algorythms with qsort.
@@postbunnie `strcmp()` is obviously the fastest, closely followed by `g_strcmp0()`. Then comes `strcoll()`, which while gives a much better result than the two before, but it was about 6 times slower than `strcmp()` on my sample size. Then at last place was `g_utf8_collate()`. While it gives the best comparison, it was still a whopping 90 times slower than `strcmp()`. So if you want to compare a very big number of strings, it might be more efficient calling `g_utf8_collate_key()` on each item once, then comparing those values (which is what the function description said too).
I have to write clever code because the platforms I work with are so poor. You just have to in order to get things to work. I will never apologize for having a hacker mentality, and impressing others isn't my goal, it's just an occasional side effect. I do comment my code liberally when I'm doing something especially obtuse.
im not even gonna watch the video next thing ima hear is someone saying "DONT WRITE EFFICIENT CODE AND HERES WHY" all of this is bullshit im not even gonna bother to watch it
Here is a piece of clever advice I always follow: If you compare a variable with a constant, always put the constant first. Remember that Linux exploit from a couple of years (decades?) back? It went something like this: if (uid = 0) {do something as root} It wouldn't have worked if all your code would use if (0 == uid) {do something as root} It looks weird at first, but that's exactly the effect you want.
I suggest keeping strcpy as comment, to qualify 1:34 even for productive code: while (*d++ == *s++); // equal to: strcpy(d, s); Otherwise agreed with everything.
Worst example I ever saw was when I built a (static) HTML homepage for our university department and then they gave it to a “programmer” who turned it into unmaintainable OO-wrapped code like $wrapper->table()->tr()->td(‘content’)…
Theres no problem with clever code if your doing something specific. Something like Quakes fast square root algorithm is a prime example of clever code is done right. The key is don't start with clever code. make the straight forward version. and when you make that clever, faster optimization leave the original code in a comment so people can see what you were doing originally in detail.
I...mostly agree. If you're going to be working for me, well DOCUMENTED code is mandatory, so the documentation better make it clear, in which case it is easy to debug. Second, in MY book, "clever" code is simple, easy to understand, is isolated and easy to debug, though if it's clever there literally will be no need, and is the most robust way to code that operation. In other words, clever code is well written code, works as advertised and is isolated enough to be unspoiled by random programmers adding stuff to the program. If it needs debugging, it ISN'T clever code.
Clever code: Easy to read only if you know how you did it. Unreadable to others or you 3 months later I only write limited code because i started programming on my texas instrument my variables are A,B, ... !, $, ... you can avoid forgetting how you did it by adding comments to how to use variables (made a RPG with 30 variables) (+ 2 pictures out of 6 max) If you don't write clever code, it might be slower than expected.
Yep, nice advice. I'm working on an embedded GUI project where I've done different structures for GUI tools like buttons, sliders .. etc. Then I developed functions to draw and read them all in C style. But I'm also thinking of finding a better work in C++.
The while-loop is not an example of clever code, it is straight forward code. The message of your video should be: "Don't reinvent the wheel." Using strcpy() is clever code because it is easy to understand and is guarantied to be correct and the strcpy() code has been optimized by clever people and is hence probably faster despite the function call. BTW - its exactly how K&R implement strcpy() in their book.
Vector based loop unwrapping in Matlab/Numpy/Fortran. It makes code slick, fast, and nearly undecipherable as the dimension of the array/matrix/tensor goes beyond 2.
For real. The best code is not broken or buggy and reads really simple. Idc if your variable names are like "ObjectThatIsOnlyNeededToEditJson" At least by reading it I know exactly why you made it.
I agree that - in general - "cleverness" should be avoided, encapsulated, and commented, but that line isn't even a hiccup for a properly jaded C/C++ coder - and becoming that should be the goal of your JPs. I paused for half a second to confirm that it wouldn't have a fencepost issue, frowned because it's not bounds-checked (which is unacceptable, including with strcpy), and then I moved on. Pointer increment copying is common among old assembly people because it's intuitive to them, so you're going to run into it sooner or later. The blockless while syntax is annoying, but not really puzzling unless you want it to be. It also doesn't cause problems in debugging. If you drop a breakpoint on that line any sane debugger will stop there once per iteration like it should. That said, I'd only ever write something like that while cowboying to check an idea or writing lazy pseudocode, etc. Otherwise I'd be using proper containers and well known (bounds-checked) functions because that's what they're for and they make the pain go away. That and bourbon.
I frequently say, that there are 3 levels of programmers. The kevel 1 beginner writes simple code, because he can't..., the advanced programmer writes complicated code, because he can, the professional programmer writes simple code, because he can.
I beg to differ. I dont like the idea of writing slow "clean & simple" code in favor of the better & faster "clever" code. What I would do in such a situation is that I would wrap the clever code in an appropriately named function ( example strcpy_fast() or custom_strcpy() ) so that its easy for other folks to understand. I mean whats the point of spending time & effort to learn to be "clever" if you are withheld by your peers? Just write good code comments explaining your implementation, document neatly & test your code against a lot of test cases including edge cases (these are stuff that any good software engineer would follow). And in most cases, as time passes & the performance of the application becomes a priority, then you'd end up implementing the clever solution anyways! TLDR: Just be a good programmer. Don't let the mediocrity of others affect you. Write self documenting code, test everything & abstract away "clever" code so that its still maintainable.
