Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks

Kevlin Henney
It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, however, is rarely arbitrary and random in its structure or formulation.
Systems of code, well or poorly structured, emerge from systems of practice, whether effective or ineffective. To improve code quality, it makes more sense to pick apart the specific practices and see their interplay - the cause - than to simply focus on the code itself - the effect. This talk looks at how a handful of coding habits, design practices and assumptions can systematically balloon code and compound its accidental complexity.
NDC Conferences
ndc-london.com
ndcconferences.com

[@DoubleBob]

Protip for beginners: If your supervisor has created this legacy code and you make it into something good, prepare for passive aggressive backlash.

[@pdorism]

FernestHall actually my boss let me rewrite the whole thing from scratch. To be fair we're not programmers.

[@rmrbush]

If you're a "beginner" you might want to take the time to understand the code before making any decisions. It's not just learning the code either. When you come into a new organization, it's also learning the business rules, the culture, and software road map.

[@monad_tcp]

I was a supervisor programmer and was like: please rewrite the crap I wrote 7 years ago

[@ITech2005]

@@rmrbush Bingo. There's usually a reason for strange code being where it is. As a newcommer to the project, even as an experienced developer, you don't know the intent or situation that led to them putting it there. It could've been a work around for some weird and obscure bug that will bite you squarely in the arse. And of course the guy that wrote it is no longer around the explain the why.

[@loam]

It depends. I have exactly that situation you described, but not because I turned legacy code into something good, it's because my lead's special features. He is previously country boy who worked remotely, then moved into city (Moscow) to work where I have occasion to work nowadays, because he had already too much made for that company and they couldn't get rid of him. I, as a middle developer, have much better potential, I speak English, I speak Russian without silly mistakes he make, etc, I learn fast, so I see now he envies me, and the strange passive aggressive moves he make (like country boy's trickery, which he probably thinks are smart tricks, but to me fairly obvious) are clear to me. At my previous job I had exactly opposite situation: less money, bad attitude from HR, but awesome colleagues and lead, and now, by contrast, I see how much awesome they were. For instance, Ivan, the guy who sat right in front of me, was really really good man, pure gold. He taught me a lot, he never been angry while explaining something to be, like a real good teacher; he always was glad to my success. And furthermore, he liked my pronunciation and when I kindly pointed out some mistakes he made in pronunciation of English words, he always understood that I wasn't trying to offend him, he gladly would take it into account and even pronounce the word or whatever it was that I mentioned several times in order to learn, to become better. Not to mention that he spoke Russian language clearly and there was no need for me to correct him, actually he also had that interests in languages that I have. Overall, really really good man, and I miss him. The guy like him is something rare, as I see now...

[@ekszentrik]

"Stop trying to communicate and just communicate" is actually career-changing advice.

[@cheaterman49]

Agreed!

[@mfaizsyahmi]

try not. do, or do not. there is no try.

[@wontcreep]

@@mfaizsyahmi you need to try in order to catch

[@winmine0327]

Advice the speaker should take. I kept waiting for him to finish his thoughts.

[@dorklymorkly3290]

"Stop trying to communicate and just communicate" means little out of context.

[@NotMarkKnopfler]

Sometimes code isn't re-written because it's "bad". It gets re-written because somebody has a different opinion on what "good" and "bad" code is. You don't necessarily end up with "better" code. You end up with different code. Rewrite culture is definitely a thing.

[@davidphillips7435]

I call this refactorbating. You do it to pleasure yourself and when it's all done nothing has been accomplished.

[@formes2388]

@@davidphillips7435 Actually - refactoring code, can be a good way to actually parse through the code and come to fully understand it. Better to be done on small bunches of code. And while yes, it takes awhile, consumes time, it is also an opertunity to understand. Refactoring code is also a good way to go through code that lacks good commenting and documentation, and create that documentation as you go - so that it's easier to understand going forward. So while doing it for the sake of refactoring the code is pointless - there are reasons to do it, and benefits to be had by doing it.

[@QuantenMagier]

True and the worst part of this is the build system. Instead of using and improving the existing Autotools or CMake, every programming language and IDE started coding its own make system.. I remember a git repository with a fine Autotool build system, but some library was outdated and then someone submitted a merge request for a different build system that fixed nothing but his ego.

[@homelessrobot]

@@formes2388 unfortunately, it destroys everyone elses existing understanding of the code in the process if your refactoring goes into a shared space. And especially if there is consistent refactoring going on in that space. I am not really in disagreement with what you are saying, because you do address this with 'better to be done on small bunches of code'. I am just pointing out that the reason this is a good idea is because of a large negative consequence of refactoring. Several actually. So if you don't limit refactorings to a narrow scope, bad things happen.

[@luckerooni1153]

@@formes2388 The one thing I hate the most about development and programming is no one can just accept that something is just not the right thing to do or is the right thing to do. Everything is so convoluted and everyone's ego is so massive they cannot accept defeat on even the smallest things. Changing other people's code just because you feel like it's wrong is just not beneficial in a team environment. You seem like you're trying to play with it in a personal environment. Neither you or OP are stating proper context so there is no right or wrong answer, but generally speaking, refactoring "just because" is just playing around at best and making people's work harder and more confusing at worst.

[@another-person-on-youtube]

"There's a lot of developers who can't program." True. There's a lot of programmers who can't develop, too.

[@ravens01]

Very true, two different skills, both necessary.

[@charlestaylor9424]

I've met the odd programmer that can't program.

[@charlestaylor9424]

Sadly the last time I met her she was teaching programming in a college.

[@sukhmandersingh4306]

@@charlestaylor9424 you've met my teachers

[@josephvictory9536]

sad programmer noises.

[@bryanbisimotopinas345]

11:09 "Sometimes when you approach the problem from the wrong angle, you can really make it something of it" is so relatable.

[@KallieExperiments]

"All roads lead to stackoverflow". Yup

[@kornbread5359]

LOL

[@Joe11Blue]

That's what virtualization and load balancing are for.

[@independent4626]

😀

[@Newtube_Channel]

No. SO encourages you to ask very specific questions. Perhaps that's in of itself is a lesson to be learnt.

[@vinzer72frie]

Not really that meme doesn't make sense most answers are either outdated or plain wrong

[@Technomancr]

I disagree with the point on imports. The only time I ever look at imports is when I'm reading someone else's code, and in that case I want to know exactly what package a specific class is in. Using * imports would mean I have to guess which package it's coming from, or I would have to have the project loaded in a tool that can calculate dependencies for me.

[@nullid1492]

My IDE shows alloc::collections::vec_deque if I hover over VecDeque so I know what package it is from without having to scroll to the top of the file and look through the imports.

[@SomethingPuffin]

Additionally in other languages, like for example Python, it is considered bad practice to just wildcard import everything

[@johnrice3675]

​@@SomethingPuffinbut that's exactly Kevin's point. WHY is it considered bad practice?

[@nelsyeung]

@@johnrice3675 I don't know about other languages, but it's bad practice in Python because of its dynamic type nature. When there are name collisions, you literally won't know until runtime, unless the libraries you used have proper type hints and you use mypy before you run your program. E.g., if a library has `def foo(a): return a + "b"` where `a` is supposed to be a string, and another library has `def foo(a): return a + 1`, where `a` is supposed to be a `float`, then only at runtime, you'll get an exception. Even worse, if the latter library has `def foo(a): return int(a) + 1`, then your code runs fine and just gets the wrong result, which will likely be well hidden in real production code. Also, Python has a module system where you just do `import foo; foo.bar()`, so you know whatever function you are calling is from whichever library. This makes your code clear where each function is from, so you shouldn't be importing everything and making everything ambiguous. Because of this, devs are even encouraged to use the same name for functions in different libraries so it's consistent (e.g., `dump` and `load` are functions from many standard and third-party libraries), so collisions are likely to happen.

[@anthonychurch1567]

@@johnrice3675 As he said if you have multiple packages imported and you use wildcard someone else can't tell what comes from where without going through the docs for everything imported to find it.

[@ruixue6955]

7:50 bad code example 9:18 problem: 14:00 fizz buzz basic code 19:52 table lookup way 20:22 problem: havent got rid of the second check 21:05 answer in JS version 22:45 Cargo cult programming 32:33 is too many imports in your code a bad thing 33:38 avoid long imports by using wildcard 38:30 another aspect of Cargo cult programming 45:04 46:37 ConfigurationManager 47:43 Configuration is way better 47:48 ConditionChecker 48:40 Condition is way better

[@kevinwilson1218]

Dont know if this existed when this talk was given but padStart would handle this initial bad code example

[@herp_derpingson]

The indentations are making me so uncomfortable

[@youssef2366]

@@herp_derpingson i like them

[@nicholascarson5509]

@@youssef2366 found the python guy

[@youssef2366]

@@nicholascarson5509 I actually do use python lmao

[@Jcarr250]

"It's a stringly typed system"

[@ishdx9374]

so, bash?

[@charlestaylor9424]

@@ishdx9374 snobol

[@bigcheesetaste]

Frankly, if your code has too many imports, the issue isn't that you should be using wildcards. It's that your class is doing too much all by itself. Half the reason it's recommended that you import everything explicitly is exactly so that you can identify it as a code smell.

[@GuyPaddock]

This, exactly. IMO He should have just said to stop folding imports but not suggested using wildcards, because both folding and wildcards hide the real problem. Java is also rare in that it even supports wildcard imports. Header-based languages like C and C++ absolutely require being specific about what you're importing (unless your headers have multiple types defined per header, which is another code smell). Even JavaScript -- the language he uses for a lot of his examples -- requires explicit type imports.

[@fenxis]

Too many imports? Yes... let's wildcard it to import even more🎉/s There a reason wildcard imports go against many style guides.

[@streettrialsandstuff]

Using FQN imports are good practice BECAUSE if you need to replace some class with a class with the same name but in a different package you can perform find and replace. This really happens in the Android world, for example when we had to use backward compatible DateTime API, and once enough Android devices with a newer version were on the market we could drop older device support and use native DateTime apis. There were other cases when we needed to find and replace all usages by FQN.

[@kaelon9170]

@@fenxistbf changing a bunch of imports to a wildcard import does NOT mean more classes are imported in the end-result. On compilation, the Java Compiler figures out exactly which classes you are and aren't using and only compiles the bits that are needed to run the program into the executable assembly. With that knowledge, I'd say that importing specific classes over a wildcard import achieves nothing of value and only adds noise to the code.

[@traister101]

​@@GuyPaddockThe thing with header based languages is you _also_ get the headers imports which is hard to notice unless you memorize/look at the entire include tree

[@BryonLape]

"We don't touch the sacred defaults." I must really be a heathen as that's usually the first thing I change.

[@AndrewErwin73]

You are a heathen... but progress requires heathens!

[@Trezker]

Those darn defaults are always wrong.

[@landonpowell6296]

If you have to change your IDE's defaults, use a real text editor and tmux/screen.

[@markuslachinger]

You mean use a real text editor with a real tiling window manager, right?

[@landonpowell6296]

+Mihail Malo Sway is pretty cool. I wish Xmonad would run in Wayland. +Markus Lachinger Nope. Sometimes I don't have the time to install Xorg, which is basically only useful for running a web browser.

[@cmbasnett]

I worked at a company with a guy who committed almost every enterprise programming sin mentioned in this. He was absolutely obsessed with making wrappers and abstracting the most basic functionality into monolithic classes. If I every asked him why he was doing it, he would tell me that it is "good design".

[@santiagomainetti9179]

I've experienced these response to similar situations: "It's best practices", "SOP" and "I have 30 years of experience"

[@milanstevic8424]

that's not a problem. the real problem is that such people work really hard to embed themselves in the social hierarchies of such companies. I had more than one boss that was like this, coercing me to comply with the "standards". I had to quit the job every time.

[@ClokworkGremlin]

I worked at a company fresh out of my programming degree and the entire management and senior developer population were in love with a lot of these sins. I'm really glad I went rogue about 8 years ago and started doing whatever I wanted. A lot of it turned out to be exactly what he does here.

[@milanstevic8424]

@@ClokworkGremlin I am sincerely happy for you, because people mostly don't have a relevant point of comparison, when they get to work for a huge company fresh from the studies. They quickly learn to instead adapt semipolitically and carve their own economic and existential way through it, while the code and software engineering is literally a necessary evil used as a social trading commodity, something that becomes less and less important as the time goes by. In the end, that picture is the state of the world we live in, anything we do isn't actually the first order priority, and there is almost no responsibility involved (unless it ends up being a disaster, then a lynch mentality goes off), and this has become painfully apparent.

[@godDIEmanLIVE]

​@@santiagomainetti9179 Means: I learned to write shitty code 30 years ago and I refused to learn anything since then. It's a shame and it really is the completely wrong mindset for this craft.

[@MrHatoi]

Wildcard imports in Java would be nice if they didn't cram so much into every single package. Seriously, it feels like they just use the java.util package as a dumping ground for anything they didn't already have a package for; it holds pretty much every data structure in the entire language plus a few other arbitrary features like Currency and Date that have pretty much nothing to do with anything else. The other major issue is that wildcard imports erase the data of where each class you're using actually came from. This isn't an issue with the standard library, but it can get pretty bad with large codebases importing code from other packages in the same codebase. Without IDE indexing features it's basically impossible to figure out where any class in a file with wildcard imports came from, which isn't very nice generally.

[@beeble2003]

But that (navigating a large code base) is exactly what the IDE _is_ for!

[@4rk]

I was told that for a large code base with continuous integration, the savings in compile time of not using wildcard imports adds up quickly enough. Additionally accidentally adding a name that collides in some oft used package break compilation of some projects' wild card imports and requires broad scale manual fixes particularly in a monorepo.

[@beeble2003]

@@4rk Does it have any significant effect on compile time? Has anybody actually measured that? "import" is just a namespace thing -- it doesn't cause any extra compilation. I can imagine a tiny cost from the compiler having to check each package when a class is used, but that should be insignificant against the other things the compiler has to do, and a class that's importing many packages is probably trying to do too much anyway.

[@trejkaz]

I sort of have the same issue. It's relatively easy to spot someone importing a StringUtils class from the wrong package if you're not using wildcard imports. If you use wildcard imports, and I have to read your code, you are making me manually search through all the packages you import for every class you use, to figure out which ones come from which. Because I'm not fond of doing that, I find it's far easier to ban wildcard imports.

[@4rk]

@@beeble2003 it's been measured, but the document I saw measurements in is no longer accessible to me. To be fair Google had a unique project structure, build tool, distributed complier cluster, cached intermediary objects, deterministic binary output, source mono repo so large that most of it was network mounted with only a few of the subdirectories you're working on actually locally available and a file system in user space helping to map things for the ide. So ymmv.

[@waytospergtherebro]

"Recursion is so cool it obviously belongs absolutely everywhere and should form the basis of every interview process." - A 22 Year Old CTO

[@gaunterodimm3569]

I love how almost each and every video in this channel is simultaneously educating and entertaining!

[@BangkokBubonaglia]

Re: object oriented naming around the 40 minute mark. This guy has obviously never written a patent application in his life. Coming up with the most general description for a means of doing something has been refined by the legal profession into an art form. Once you start working with patent attorneys on your inventions (method patents are legal in the USA), you will never, ever again call a door a "door". Anyone worth his salary will automatically start referring to it as a "Selective Passage Or Inhibition Means". And management will reward you handsomely for this, because it shows you are thinking outside of the box and into the future. 17 years later, when your code is being used in a trial between 2 multinationals who acquired your small company (in a deal which made millions for the management), the fact that you never once said the word "door" will mean that one trillion dollar multinational will win a multi billion dollar lawsuit against another trillion dollar multinational who tried to replace your simple door with a laser activated safety screen and patent it as a new innovation in the field.

[@Lttlemoi]

Having only started with Objective-C(++) less than a year ago, I lost count how many times I wanted to look up and strangle the person who came up with that language's naming convention. *"Nonono. Having a function **_doThing(ArgType):arg_** and another function **_doThing2(ArgType):arg (Arg2Type):arg2_** is **_bad._** You should call these functions **_startThingDoerWithArgument(ArgType):arg_** and **_startThingDoerWithArgument(ArgType):arg andSecondArgument(Arg2Type):arg2_** "* - some daft maniac who really likes poetry, I suppose. The only reason why we stuck to this style for our iOS code is because other iOS developers expect this style. Repetition does indeed increase truthfulness. No wonder people have huge full HD or 4k monitors these days. It's in an attempt to fit method calls on one line.

[@Machtyn]

Speaking of code commenting. In school, high school or college, it seems in the beginner programmer courses the teachers are quite adamant about adding comments. In high school, they just don't add comments and so the teacher pounds it into their head to document every line. In college, the comments may be sparse among the spaghetti code that gets turned in. The professor comes back with "add more comments," and docks points. I had dev experience when entering the beginner Java class at university and, of course, commented the necessary lines and it was a nice bit of code. The student aid came back with "add more comments." Oooh, boy... did they ask for it then!

[@NovemberOrWhatever]

I've had that happen to me as well. Not coupled with them saying they didn't understand it, they just didn't feel like there were enough comments. It's 25 lines of code where large parts of the assignment involve print statements. I used reasonable variable names. That doesn't need comments

[@webentwicklungmitrobinspan6935]

dont get discouraged, i worked on clean code projects without comments other then very niche details and it worked well. i never had a issue of understanding the software written

[@Sahuagin]

yes, in university they don't want to read your code they want to read your comments.

[@judithflow3131]

Exactly the same here, once got the requirement to add more comments, when I already had a lead in comment on every single function defining input, output, explaining train of thought and including edits *and* kept every function between 3 and 15 single statement lines of code (since I hate combining several actions into one long 3,000 character line of code). So they eventually found quite a few Playboys worth of ASCII art in there. The other thing I hated when reviewing code, was how some people turned everything into a function, nesting functions within functions within functions, to eventually end up with a function like TestIsHigher(a,b) {return (a>b)} when this outcome was something required several layers up in the hierarchy. At that point, it's no longer programming, but it's unnecessarily renaming of standard functionality of the programming language. Oh, and the function right above the one I mentioned in hierarchy was called something like DoTest(gTestType, a, b, c, d, e) which then split up to all these little single line functions depending on what globally defined type of test was required. And yes, there were some 60 global constants defined somewhere for each type of function, and yes, calling DoTest did require including arguments which might not be used or even be available by the calling function.

[@thomasmaughan4798]

I learned old school programming -- structured, indented, commented. Can you remember YOUR OWN ALGORITHM six months later? Never mind maintaining someone else's program. So in college it took me longer to complete a programming assignment because my homework was nicely structured and commented. The professor, who unfortunately was also the dean of the computer science department, said, "What did you do all that for?" and I was speechless; "What, everyone else is NOT?" EDIT/Add: I program mostly in "C" and used to do rather a lot of assembly language programming where the task is NOT obvious by inspection. Even in "C" the task may not be obvious and the example Javascript is very much non-obvious such as where did pad.method(x) come from? Well, probably because "String" is a class with methods and pad = String implicitily adds a whole library of non-obvious functions (methods) to what you thought was a simple string variable, "pad". I am reminded of Gary Larson's cartoon, "a miracle happens here".

[@lennysmileyface]

I like seeing: /* * The id of the object. */ private int id;

[@JesseLH88]

//My reply to you String theReplyToYourCommentString = "Yup."

[@HrHaakon]

That is literally banned in our codebase. You're not allowed to do that. Straight to jail.

[@__gig__]

my old university was guilty of this. the automatic code-grading system required students to have javadoc-like comments for every single field in a class -- you'd lose "style" points if you forgot them -- so there were lots of lines of code exactly like your original comment.

[@gnack420]

That's not a comment, technically, even though it is treated as such by the compiler. It's more akin to a decorator or an annotation. It has an actual purpose which is that it is read by docs-generating software (and IDEs). It's definitely "pointless" for the person reading the code, but it's going to be there for consistency so that you get docs for every field instead of just arbitrary ones.

[@HrHaakon]

​@@gnack420 Depends on language. Maybe some C preprocessor does it? IDK. In Java you have /** This is a javadoc comment */ and in C# it's /// for documentation comments, IIRC. Why you'd not have some way to tell your tools which comments to care about I have no idea.

[@nosirrahx]

I watch a lot of these lectures and I always take the same thing away: Damn, I am glad that I am retired and code fun little projects for myself.

[@malusmundus-9605]

I code only for myself and I think EXACTLY this

[@edgeeffect]

For work, I write Enterprise-grade GUK! For my hobby projects, I use assembler with less than 1K of RAM... It feels like taking the thumbscrews off.

[@grapy83]

Damn! I envy you sir... Good Job and happy living.

[@robwillett4960]

Me too lol

[@matthewsheeran]

Nothing beats your own single developer projects with consistent conventions across the codebase booyeah!

[@monstertrucks9357]

22:14 " _...and we've reduced it to its essence, and we can wander around feeling mathematical, functional, and remarkably cool, and also very certain of our jobs. So there's this other side to Enterprise Programming that we see in a number of cases, and again I want to refer to this point as being Art: It's clearly a unique result of a unique temperament..._ "

[@RARufus]

We run software that about 80% of the companies users rely on every day. When designing an API, I mentioned to the enterprise architecture team it was an enterprise document API. They asked if it accounted for all documents for all systems…I said no, just our teams system which accounted for 99% of all documents in the company by volume. He remarked that it wasn’t an enterprise API then and it was an application API. I said “sure” and moved onto the next thing in he meeting.

[@lucasterable]

Other examples of import collisions: - DateUtils (apache.commons vs apache.http vs of.course.your.own) - Function (java.util vs various spring packages) - List (java.util vs hibernate) - Collection (java.util vs hibernate) - Map (java.util vs hibernate) - Optional (java.util vs bytebuddy) - StringUtils (apache.commons.lang vs apache.commons.lang3 vs of.course.your.own) - Date (java.util vs java.sql) - Assert

[@tonnentonie2767]

junit vs junit.jupiter

[@imadetheuniverse4fun]

Yep, the wildcard import advice is really bad. Just import the module itself if you need a million functions from it.

[@rolfs2165]

@@imadetheuniverse4fun The most baffling thing I've seen was fellow students importing _the entirety_ of apache.whatever for String.isNullOrEmpty(). Like, for one you don't need to add several megabytes of unused imports for that, for two, that's a freaking one-liner to write yourself! I've only tutored Basic VHDL, so includes and such came later (meanwhile we had half of the class "doing their homework together" - with students from 10 years ago), but that would have been a serious "explain why you're doing this" moment for me.

[@originuk]

@@rolfs2165 Brilliant post! I agree with that so much! Students are now told to not bother re-inventing the wheel. There's already a library to do what you need, and the authors will understand the problem better than you. Right, so there's no point in understanding the problem either? Yup... That's character building. If you're going to stand on the shoulders of giants, you'd better be sure they're standing on solid foundations first.

[@originuk]

If the IDE giveth and taketh imports... the IDE should figure-outeth the correct import. If the project has now java.awt imports, it's highly likely the project needs java.util.List....

[@jeromej.1992]

The problem is often not so much the variable name but because your code does too many things so you have difficulties finding simple names, and often, I feel, it indicates much required refactoring / decomplexification instead of renaming. Renaming can't help you there.

[@RyanLynch1]

agreed

[@jeromej.1992]

@Harshil Pandey Many. There are a few ways/tricks to achieve cleaner code. Try to separate your input, the logic and consequences (the persistence). This helps your code being more readable, more plug-and-play, more easily testable,...

[@TehPerz]

Local variable shadowing lets you reuse names of variables you no longer need rather than try to make up new names that mean the same thing. Too bad a lot of languages don't support it.

[@pt8306]

Singletons do have one use and one use only - when you need an object that only ever exists once, AND you need late initialisation for some reason. Otherwise you can just use a static class. I know static classes are considered "evil" these days, but there's really nothing wrong with them if you are literally, genuinely and seriously only ever going to have one. People don't like the "you call functions on the class not an instance" aspect, but that's literally the whole point.

[@wmrieker]

...or the class implements an interface that you have to pass to something.

[@pt8306]

@@wmrieker If you are at a point where you need to pass a generic interface around, a singleton isn't appropriate anyway.

[@bdijkstra1982]

@@pt8306 an empty collection could be a singleton.

[@pt8306]

@@bdijkstra1982 Nah, you're better off using a static const

[@arjandikhoff5201]

One caveat is that static classes can cause problems in multithreaded systems.

[@redstoneprojectrules]

Can we just all respect the eye-strain friendly slides?

[@peceed]

1) Import list is not a noise, it allows you to know the exact class of used types regardless of IDE. Without that your code is fragile and can stop compiling when imported packages are extended by colliding names. What we really need is the syntax like: import java.util.{List, Map, HashMap}. 2) Use f*** IDE. 3) Don't hesitate to use refactoring support in IDE to rename types and variables later. 4) Example names are trivially misleading, it is list of "cult cargo naming".

[@robwillett4960]

I loved this talk. I retired last year (2021) but have seen this kind of stuff throughout my entire career in one form or another. Management don't understand any of this and people get promoted to positions where these practices are imposed on people below them in the hierarchy. Glad I'm out of it. Well done Kevlin.

[@xcoder1122]

1:01:12 Actually C once required you to make all declaration on top of a function. Not sure at which version of C that changed but as many people like to write C code that can be compiled with oldest compiler the world still uses, even long after that has been changed a lot of code was written that way and of course other programmers copied that style. Also very early compilers did not reuse stack space and by having all declarations on top it was immediately possible to see how much stack space a function requires (already), which was important in very limited environments, especially if you planned on calling it recursively.

[@mettaursp309]

I believe C89/90 required it, while C99 didn't. Must have been either C95 or C99 that changed that. I definitely remember that restriction from uni projects, and I vaguely remember seeing that some of the messes like that were cleaned up in C99 code elsewhere. I can't say what version really changed it for sure between the two though because I quickly moved on to C++ after learning C89/90.

[@samyvilar]

I think it’s C99 since that was the biggest update to the core language, as to why declarations had to be made up front, it becomes quite obvious when implementing a C compiler, since declarations may modify the stack specially within compound statements, and goto statements allow you jump anywhere w/i a function, a naive/simple implementation of goto can very easily corrupt the stack, should the 2 be intermingled, hence for the sake of simplicity initially all declarations where made up front modifying the stack before hitting anything else, greatly simplifying things, with C99 you have to take great care to make sure the stack is in the “expected” state when dealing with goto, it goes without saying implementing goto “correctly” or at the very least “safely” is an epic pain in ass … some C99 compilers “cheat” by copying all declarations even those w/i nested compound statements to the start of the function, while replacing their original instances with initialization code, on one hand you only need to modify the stack twice, once at entry and again at exit, while also simplifying goto, o.t.h. this could use far more memory since out of scope storage can’t be reused until the function exits, thankfully most modern C compilers aren’t that inefficient …

[@MenachemASalomon]

In C (and in C++), the compiler needed to know how much space to allocate for local variables (on the stack) when entering a function (or scope). Requiring a programmer to define all variables was therefore reasonable, as there were no side effects. But in C++, defining a variable can have a side effect (such as calling a constructor), and the programmer needs the flexibility to control when that happens. So, despite efforts in allowing C++ to be implemented by a single-pass compiler (which is not possible for C), C++ had to allow local variables to be defined at the point of usage, and the compiler will have to backtrack a bit to fix the stack size. With C/C++ compilers on the market (that is, a single compiler system that could do both), allowing C programmers the same flexibility was simple enough, so it became a common non-standard extension, available (I think) on both the GNU and the Microsoft compilers by the early '90s. C99 merely standardized the behavior that was by then ubiquitous, as it did several other features that migrated from C++, such as single-line comments. (Function prototypes had been migrated to C from C++ by K&R2 in `86, which became ANSI C and then C89.)

[@therealax6]

@@samyvilar I should probably point out that C11 was an even bigger update than C99. (And C23 promises to be even bigger. I'm looking forwards to it.)

[@slipoch6635]

I prefer the curly braces for containing. that way i can always see exactly what is inside any area i use them in.

[@Baekstrom]

The C++ specs for string.data() used to state that the implementation was not required to include a null terminator, while the c_str() function did. However, as Kevlin pointed out, every implementation included the null terminator in the data, because it was the easiest way to implement the internal representation of a string, so in later versions of the specs the null terminator is now required, so the functions data() and c_str() are now identical. You can use whichever one you like, although if I was to bet on which one is going to be deprecated, if any, I would bet on data(), because it is rarely used anyway.

[@hrgwea]

I've seen the opposite; .data() is much more common than .c_str(). I, personally, always use data() because it's easier to type (and shorter).

[@briannoel7398]

.c_str() is non-modifiable (without const_cast), so it achieves less utility than .data()

[@funkiekeda]

Quite entertaining video, but the guy sure loves to talk a lot, his verbosity can easily outmatch verbosity of the code he was bashing at some point.

[@monstertrucks9357]

Yes, but code verbosity is generally always a bad thing because effective code succinctly expresses its operation. Human verbosity, on the other hand, can be a good thing...

[@Android480]

I had to stop watching.

[@casperes0912]

national holiday It’s a very different context. This is a speech with a large part of it being meant as entertainment in addition to education. And both of those warrant extra verbosity. If jabbering on makes something more fun that’s good entertainment. If jabbering on means more people will understand what you’re trying to convey that’s good education. Code is meant to be quickly and easily understood

[@prgnify]

@@casperes0912 I really wish his talk was only for education and not entertainment. It was so verbose he did a disservice to the message he wanted to give.

[@prgnify]

@@casperes0912 45:30 the cards are really ironic

[@VAXHeadroom]

1:01:30 If you're going to distribute declarations like that you MUST provide a trigger warning first :) For embedded systems I insist on declaring variables first so that an estimate of the amount of stack the variables will require can be assessed at a glance (especially on legacy microcontroller systems with limited RAM). Feel free to disagree :)

[@draconicepic4124]

Or, if your still using C, it's required. It's also required if you end up doing dynamic stack allocation to prevent undefined behavior.

[@VAXHeadroom]

@@draconicepic4124 Working on spacecraft I try to NEVER do dynamic memory allocation and to restrict stack data pretty hard. If we do use memory allocation it's "Allocate and hold forever" but I prefer compile-time allocation. I also do hand-written link scripts so the linker will tell me how much memory is used in the map file, but that's a whole other topic! :)

[@therealax6]

@@draconicepic4124 If you're still using C89, you mean. C99 (23 years old by now!) removed that requirement. I have no idea of why people think C must mean ancient C.

[@grex2595]

Wait, so in order to make the last bit of code more readable, we factor out the part of the code that converts the strings to numbers, factor out the error logging and throwing, and finally factor out the whole function, making everything the caller's responsibility. Did you not just move every line of code you just cleaned up into a function that already has other lines of code in it, making that function less clean and more complex than the original one you're cleaning up? You mostly had me until that point, but your final clean code example is effectively, "instead of splitting code into functions, just put all the code in one function."

[@cregkly5444]

Yes! I get on my soap box at work about how important names are. This is perfect and explains it better than I ever could.

[@MechMK1]

"Capture pragmatics, not statements" is one of the most profound wisdoms of one of my professors.

[@jackfirth8890]

I'm really surprised nobody mentioned the main driving reason Java wildcard imports are a bad idea: they make it possible for libraries to break you by adding new classes! If you import foo.* and bar.* to get everything from two different libraries, and the foo library defines a Thing class, then your code will break if the bar library adds its own Thing class. Fully qualified imports eliminate this possibility. If most Java code used wildcard imports, widely used Java libraries would be unable to add new public classes because odds are they'd break *somebody.* Wildcard imports are great for reading code and for library users, but they hinder library developers. Java prioritizes library developers over library users. So your code will always look a little noisier than it needs to, but on the other hand, there's a *ton* of great libraries to use that have been around and continuously maintained since the dawn of time. (I'm a Java expert and library developer working at Google)

[@TonyCoyle]

If a library changes, you should be considering the impacts of that change ANYWAY, so your example is simply that (in update X, library Y added new func Z. Exsting func Z from A.B is therefore fully expressed). ONE line gets added to your code WHEN NEEDED. And you have another opportunity to refine and revise.

[@MD-vs9ff]

@@TonyCoyle One line in how many different source files?

[@kylewilson4097]

On comments, one I encountered was a function that was written by one developer to clear out working files from a scratch folder. It only removed files and did not recurse into subfolders. He created it for that one purpose. He had no subfolders in the scratch area he used this on. A few years later he had added subfolders with other scratch data and updated the function to handle this and walk the tree deleting subfolders. In his mind this is what that function was intended to do, it just didn't need the folder walk until then and this was an enhancement. Worked perfectly until he committed it to source code control... The following morning the whole place was in an uproar. Turned out that the server developers had see this handy little function and were calling it to clear out working files at the top of the database tree and expecting that it would leave subfolders alone. Nothing in the name of the function implied that nor did they talk to the person who wrote it originally...they read the code and considered it self documenting. That morning every working data store in the company was deleted before anyone realized what had happened. These were working data and thus weren't in source code control and most weren't backed up in a usable form. This incident was my first revelation that code can only self-document its current intent and that only human readable comments and communication can get the bigger job done. If the function had contained comments noting that it was intended to remove sub-folders then at least the folks who turned it into a common library function would have had a fighting chance of avoiding disaster. As it was it took some time to recover from this mistake as this deleted test databases that had been crafted by various developers and rebuilding them was not always easy.

[@Mish844]

funny that you would suggest a solution that has absolutely identical problem - writing those in english doesn't solve it if the person doesn't update intent, and practice indicates tha in a project old enough you can't outright trust the comments in the first place, cuse at some point intent and comment are a mismatch. Not to mention that no code is self documenting if you don't bother reading. You're telling us that practices in that organization were so yolo-driven-development that noone noticed a diff in function that suddenly started including going down in a tree? Sounds self documenting enough, unless the entirety of the code was obfuscated beyond recognition.

[@kylewilson4097]

@@Mish844 Ah but in this case I talked to the developer and he had that intent from day one...just hadn't intended anyone else to use the function. If he had included a comment (or used a fifteen word long name for the function) the intent would have been clear...instead others used úndefined' behavior of the function and got burned. It is often easier for human beings to write in words what they intend a function to do than it is to write and validate the final functionality well before it is needed., No solution is perfect but the 'self documenting code' solution is cripplingly bad as those reading the lines of code cannot ever intuit the unstated intentions of the person who is maintaining that code. People started using the function as was and then months later the original developer added the new functionality. Automated builds compiled the code and delivered it to the pipeline and then the first time they ran anything the following morning disaster ensued. It was a poorly structured development environment but i could easily see the same thing happening at Amazon Robotics (where I worked for a couple of years) and potentially nuking things...the function would have passed all of the relevant unit tests as there wouldn't have been any to verify that it didn't recurse folders. Sometimes the native language of the developer is a better and easier way to convey future intent than code that has not been written yet...

[@Mish844]

@@kylewilson4097 my apologies, but did that developer obfuscate the code? If not the intent you describe is simple enough that you can find it... in the code, rendering the comment redundant. Not to mention that changing a big change in a code that is aleady used should raise a flag which leads me to the punchline that you shouldn't blame the rule of self documenting code if the issue was in bad habits. No documentation, including great code helps if peope don't read it in the first place. And someone writes in a team project code with intent that noone should or would use this code... Jfc, they should stop working in team projects. To summarize: the way you describe this case leads to the conclusion that the crippling component wasn't the self documenting code approach but (a) terribly inexperienced developers(s) or even outright horrible one(s). But fixing this issue with "wrte some (more) comments" is trying to close a wound with duct tape. Putting aside the issue that comments sometimes are necessary, just to make things clear, though not in a way you described. In some cases code can't contain the gist of method in which you try to solve an issue. Typically if you perform some hard to grasp but short in code operation, using a comment is a good idea. Explaining that you don't want to use recursive in files? Putting aside that's on you, because it's a simple case, if you feel like you MUST make it more explicit, you can write a simple unit test that mocks a file structure and returns failure when nested files have any changes. It's a lot faster than some would think and this way you'll actually avoid the problem of comments not being read by coompiler, cuse this method actually gives you some feedback if you make change not expected by author.

[@kylewilson4097]

@@Mish844 It was many years ago and that team wasn't great. SO your expectation is that the documentation would be supplied by the developer using the code reading the unit tests to determine what future updates to the function would do? My experience has been that unit tests get written half assed and just enough to cover the happy path (Amazon in particular did that everywhere) as proper unit tests for even simple code are 5-10 times the size of the code being tests if you're going to provide comprehensive coverage of all intetended behavior and both happy and unhappy paths. No place I've ever worked at (including life critical medical devices) has allocated time for that level of unit test.

[@kylewilson4097]

@@Mish844 From what I saw and remember the code was very simple, enumerate files and delete each file. I think the code to handle folders was simply missing and the test cases did not include folders as that was a future feature. He didn't advertise this code as a general piece of library code so I agree no one should have used it in their code (separate issue with this place as in plenty of other areas people reinvented the wheel many times over rather than putting common things in a library).

[@xybersurfer]

probably the best talk about refactoring that i've seen. the world would be a better place with more programmers like this. it's really not so hard

[@jerrykim7777]

love the part after ides where he brings up the matrix. But seriously, imports are interesting to me as it lets me quickly preview all the objects that are going to be involved and this fails hard with a wildcard import. Not a problem since I can do ctrl-d on vim a couple times or /public class and I'm instantly where I want to be.

[@LPFan33]

I kind of agree. I also feel that if there are tons of imports, it smells to me that the module is doing too many things or at least has too tightly coupled dependencies. I would rather be aware of the smell and do something about it than hide it.

[@DylanYoung]

Tells you immediately how much work it will be to remove a dependency as well.

[@ghostofrecon1]

Great talk! This definitely has me rethinking some of my coding habits

[@MuhammadShaheer]

This was quite helpful to understand some of the coding frustrations and the verbosity of the talk helps people without programming backgrounds.

[@jhoughjr1]

Preaching to the choir. This expresses well so many of the difficulties Ive seen in the last decade of programming

[@richdobbs6595]

I hate using wildcard imports, since when I read my own code I can recall all of the possibilities that I might be flattening down, rather than keeping them explicit and obvious. But I never seem to have particularly long import lists. If I did, I would think that that file had too many concerns.

[@TheExileFox]

Boost for C++ is practically a wildcard library. You can't load just what you need, you have to load the entire thing and so compiling suddenly takes forever.

[@marktellez3701]

This is exactly correct, be specific, be exact, and be descriptive and you never need a comment

[@57thorns]

Something else that is funny (that I know some IDEs will try to help you solve): If you switch from one implementation to another (say collections.List to collections.Set) your List import still remains, despite not being used. So the list always grows, unless you IDE decides to delete the line for you, in which case the next time you want a List the ide adds list from std.List, not collections.Listm which has slightly difference implementation and semantics, and vastly different performance.

[@kaelon9170]

Most IDEs allow you to run code cleanup (and code formatting, if desired) upon saving the file. I have this enabled so that all unused imports and local variables are removed and the code is reformatted on save. At work we also run checks for this in the build pipeline for PRs, to ensure people don't introduce unused imports or variables in the codebase.

[@NOLFLON]

"If you get the names right, you are communicating design" : 43:16 Leading into real code examples of "Stop trying to hit me, and hit me" (renaming methods/classes to make it clear, specific and concise) : 46:40 and 47:46

[@TheOceanLoader]

My tip to junior devs: Study everything everywhere. You should doubt everything is anywhere better than you can make it, but be humble enough to spot good code. Tools are everything - so master your IDE and learn keyboard shortcuts - in fact - all shortcuts to make common tasks as quick as possible. Also - C# is an easy transition from Java but has different coding conventions so you need to master coding conventions for different languages as per the creator's guidelines.

[@Stettafire]

This. Though the advantage of C# is that the documentation is stellar

[@mrcryptozoic817]

Speaking from experience in 2005: There are three reasons (at least, the best) to rewrite code: 1. Old code is running too slowly or is kludgey. 2. Old code is too difficult to update with maintenance (as for new requirements, or wrong language used initially). 3. Old code is hard to understand (like assembly language with no comments). At the very least, we haven't been limited to 8 byte names for at least 2.5 decades. Go through and make the names understandable.

[@mrcryptozoic817]

@@jmc000 I can tell you've never had to fix assembly language code. I've rewritten a system monitor (previously assembly ) using Rexx and can attest to a better naming convention. Those 8 byte names are cryptic and tell you almost nothing. I finally, gave up and just switched languages and rewrote it from scratch ditching the native assembler code. I could make the modules fully understandable by including a decent naming convention saying what their home routine is and what called them. So I took care of whoever followed me.

[@ericmememan4632]

looking at writing code as applied semiotics is incredibly fascinating and i would love to see more of it

[@seephor]

My test is. You know you're dealing with enterprise-level code when you can copy/paste the entire 50 file project into a single file that you can now actually read and you feel like you've accomplished something.

[@herbert164]

I understand your point, but making a monolithic file to replace multiple can be in its own right bad practice.

[@Stettafire]

@@herbert164 Agreed. For one code reuse becomes more challenging, leading to a lot more copy paste. (Also it's ugly)

[@pt8306]

Yeah enterprise code seems to be absolutely chock full of unnecessary abstractions and redirections and extremely bloated class hierarchies. When copy-pasting it all across you can usually see where the issues are and just remove those classes entirely.

[@arekkrolak6320]

Sir you have made my day with your video!

[@aloveofsurf]

I am in wow by 5:45. I already believe I have learned great lessons of my life from his trip to the dictionary as pedagogical enterprise.

[@RonJohn63]

16:20 This reminds me of a group project (written in Turbo Pascal) that we had to do in college back in 1985. My team's code was about 60KB (and worked except for a couple of corner cases), while another team's was *three 360KB floppy disks* just to insert, modify and delete data from an inverted list.

[@ME0WMERE]

sometimes abstraction and whatnot is good, but jesus, there is a limit

[@CuriousCritter9]

To be fair, the devil lies in the corner cases. They are really important, as bugs tend to show up there only after a while, when the code is well in production. It's easy to make something that works 90-99% of the time. It's hard to make something that works 100% of the time. But I guess the 15x difference in code size sounds a bit much even to handle a couple of corner cases. Personally, though, I will almost always prefer large, correct (and even slow) code over small, buggy (and even fast) code. The ideal is fast, small, and correct, but correct is always my primary goal. Make it work correctly, and then refactor to increase the speed and decrease the size if needed.

[@RonJohn63]

@@CuriousCritter9sure, make it work, no matter how suboptimal, but 18x larger is just Bad Design. Just as importantly, "quantity has a quality all it's own"; all that extra code is more surface area for bugs.

[@krzaq666]

As of C++11 string::data() and string::c_str() are equally good. It's also weird that the leak of a Connection object in the original code (in case of throwing an exception after it was created) wasn't touched upon.

[@timseguine2]

I was also surprised he didn't mention the memory leak. Memory leaks love to hide in code like this after all.

[@ShredST]

He changed it to a unique_ptr. What else did he need to do?

[@MD-vs9ff]

@@ShredST Mention it before changing it. It is still a bug in the original code that's worth bringing up.

[@SemiMono]

In the final section, where he refactors some code... Good refactors, but deceptive. The only actual reduction in code was a few conversions from old-style to new-style, namely using managed pointers from the start and using exceptions from within the connection class rather than converting an error result into an exception. I think to fully understand the simplification of the code we ought to be able to see the changes made to the surrounding classes.

[@manaquriazertyuio4555]

yeah, basically half is moved to the constructor, and the other half to whatever function is calling, and we probably don't want to deal with the configuration so we write a `connect to server` that takes no parameters and fetches the address and port from the config, and we're basically more or less back at square one (though some part of the log and throw would be done in the connection)

[@SemiMono]

@@manaquriazertyuio4555 Right. I think that architecturally it was better to move those things outside of the function... PROBABLY, depending on the context it's used in. However it still seemed like he was making himself look smart... or something... while he was actually just moving things around. Depending on what actually used this method and the scope of the refactor he was undertaking, this might actually be a bad change (not everything he did, but getting rid of the method and moving the configuration access etc. out). What if that connection class he modified is part of a library? What if you have 150 different places this function is referenced that all now need to read the configuration themselves; is that really in scope of the refactor you're doing? Etc. etc.

[@erkan2284]

@@SemiMono `What if you have 150 different places...` actually his way makes better because now 150 place can use different configurations and you can test this method, and also yes refactoring 150 place is hard, so usually you don't change the original version of the method and push refactoring 1 level deeper and your original method becomes adapter between refactored and non-refactored version of your codes, when you keep refactoring everything you change it to the cleaner version and your code always works.

[@zechordlord]

@@erkan2284 [[deprecated]] attribute in modern c++ works wonders there.

[@milanstevic8424]

@@SemiMono you didn't quite understand the point of his 'refactoring'.

[@gnack420]

We need to bring back 'thenceforth'

[@zyansheep]

Agreed

[@ekszentrik]

Thenceforth it shall be used again.

[@celebrim1]

Did it ever leave?

[@tony1923]

Sooo close ... I was in agreement with him until the last 2 minutes. Where he basically extracted the responsibility of checking config input values out of the function he was refactoring. He didn't refactor 30+ lines of code down to 1 line. He refactored down to 1 line + x lines in a function calling that function or single line.

[@GonziHere]

I would call it a comedic effect. I mean, even the first code was impressively bad. It did ilustrate the point quite nicely.

[@EmberQuill]

I've worked with several people who are guilty of "over-enterprising" their code to the point of absolute ridiculousness. I still remember when one of my colleagues took a fairly simple problem (check if a new server instance has the proper tags applied when it starts, terminate the instance and email the owner if it doesn't), and abstracted it out into this modular enterprise-ready mess that I never could quite understand. He liked to throw around the phrase "orchestration layer" so much that it lost all meaning. It grew like some kind of infection for about six months before it was quietly canceled and left unfinished due to our old boss leaving and being replaced with someone who changed around a lot of our priorities. Meanwhile, AWS had introduced their own solution for tag compliance that was fully managed and required minimal configuration. In fact, it may have already existed when our solution was still in development.

[@programaths]

27:36 Comments can be used for WHY, not how. Most languages have systems to document assumptions and even have them checked in debug builds. It's also possible to use comments for code that is not self explanatory, but written that way for performance reasons. One can't assume everyone has the knowledge. One example is the "fast square root" or even if one need to compute some terms in a series.

[@programaths]

Was kinda 60 minutes early with that one 🤣

[@dsmyify]

We change the tool and the tool changes us. IDE edition. Thanks for sharing.

[@TroyNiemeier]

I gave this video a like after the "stop trying to hit me and hit me!" analogy for naming things. Brilliant!

[@TroyNiemeier]

Another 'like' for correcting the comments' grammar before removing them. lol

[@qf6894]

The talk title discussion is really on point.

[@EricMuranoAU]

Everytime I try to hide explicit imports by using wildcards, I end up wondering where classes come from

[@RoverT65536]

toBe = nobility(suffering(fortune.slings, fortune.arrows)) < nobility(ending(arms, troubles))

[@manonthedollar]

#define QUESTION (bb || !bb)

[@artemkorotenko666]

@@manonthedollar #define QUESTION (true)

[@Slashx92]

@@artemkorotenko666 if (true) { // remove later ... // code }

[@ade8890]

@@Slashx92 if (true) { // remove later GOTO END } END:

[@karaloop9544]

10:05 Not a JavaScript programmer either, but as far as I know String() was added in later versions of the language, and I believe the same is true for String.repeat(). So to be applicable to even early versions of JS the code was a little bit more cluttered on purpose.

[@CottidaeSEA]

It honestly just seems like code that is supposed to be runnable on all JavaScript engines. I think the code looks just fine. My worry is rather in the fact that so many people depended on it despite having polyfill readily available, or not needing the backwards compatibility at all.

[@arnerademacker]

@@CottidaeSEA They depended on it because it's an insanely performant piece of code that doesn't need poly-fills or abuses the weirdness of the language in some way. It's just basic JS that runs on literally every machine and does exactly one thing incredibly well. I agree though, I think very few people needed this specific implementation. Not all projects need compatibility and not all projects need this degree of performance. And if you did, there is an argument to be made to just create your own function, following the code example that the npm package sets.

[@CottidaeSEA]

@@arnerademacker Exactly. Even if they want to have it, there's no reason they couldn't just download it and store it locally in the project, keeping all license stuff in the file, etc.

[@simondrew2914]

Having just praised his own coding practice for being brief (and presumably, efficient), he pours scorn on the use of a perfectly good word, 'thenceforth', to mean 'from that point onwards'.

[@MykhayloS]

IDE is the reason why we DO NOT NEED to include explicit import statements. Try to figure out the origin of the class once you open the code in a text editor. That is why I prefer to explicitly include full import statements, because it helps to sort the things out. If I remember it well, wildcard import is reported by SonarQube by default. So, it is considered to be quite a good coding practice.

[@adrianconstantin1132]

The way to solve name conflicts between awt.* and util.* presented here only works during development. If a new Java version introduces yet another conflict, old code that used to compile suddenly gives conflicts now and needs to be updated.

[@ConcerninglyWiseAlligator]

"let's create a problem in every file in the project because in a highly unlikely future a handful of them might have a problem" I'll extrapolate this to a slight bigger but related topic: Code can't be and shouldn't be future proof. It will most likely make the code worse now, since general solutions tent to be mediocre solutions. If the problem changes, solutions should change as well. Because solutions must be fitted around the problem to be the best solutions to it.

[@justinkendall8341]

Regarding the star imports, at first I was apprehensive about this because `import com.company.managers.*` is very opaque, but then realized that's not an issue with * importing; it's an issue with bad granularity of namespaces. So my thought on this has been improved to such: use *'s where possible, and name specific classes only when the library in question is not namespaced at the granularity you need for a clear understanding of the dependencies.

[@Roescoe]

I was generally concerned that it would slow down things if I import lots of packages. unsure if that's true, and even if it is, if it matters.

[@swapode]

I really like re-exports. In Rust it's common for libraries to have a so-called prelude module that re-exports everything for the common use case which you can then import via wildcard (use some_library::prelude::*;). You keep the internal structure that makes sense for the library but offer a more streamlined way to import/use it.

[@Spiderboydk]

A lot of this aligns surprisingly well with the manstras of programmers like Jonathan Blow.

[@lancetollenaar7905]

What winds me up is pointless dependency injection, like some interface called "IIncrediblySpecificThingDoer" and then a class right next to it, the sole implementing class of the interface, "IncrediblySpecificThingDoer" or even worse, "IncrediblySpecificThingDoerClass" 😂

[@snknsnp]

To be honest, most modern IDE's strip away import statements anyway. Therefore I strongly dislike wildcard import statements, because this pollutes your code with classes that are not necessarily intentional imports, but still very much present as imported classes. Certainly once you start working on larger projects, you will see that quite many classes can share the same name. For an easy example, consider the class `Proxy`, it is present in: - java.lang.reflect - java.net - javassist.util.proxy - javassist.tools.rmi - org.springframework.boot.autoconfigure.elasticsearch.jest - org.springframework.boot.autoconfigure.sendgrid - org.springframework.boot.devtools.autoconfigure.RemoteDevToolsProperties - org.eclipse.jetty.client - org.springframework.cglib.proxy - ... And probably a lot more. If I were to use ` java.lang.reflect.*`, it would get annoying to use `org.eclipse.jetty.client.Proxy` as well. In our company we call this import pollution. It's true that you can specify and override this, but the point is that it is often more difficult to spot which `List` is the true one. Same for `Proxy`, etc...

[@Kenionatus]

What you can also do (at least in Python) is to do "import pandas as pd" for packets that are used a lot but you don't want to clutter your namespace with. In this case I think the abbreviated name is a good idea since you are typing it a lot so a more verbose name would clutter your code. At the same time, the import statement self documents the abbreviation.

[@matheusjahnke8643]

Also, if the languages allows you, you could just import where you need it; first_function(parameters) { import *Stuff* from *Module* do things with parameters and Stuff } second_function(parameters) { import *Other Stuff* from *OtherModule* do things with parameters and Other Stuff } Sometimes I do that in Rust(for specific names I use somewhat frequently and that would collide outside the scope of the function)

[@petervansan1054]

@@Kenionatus you can't do that in Java (thank the god)

[@jocr6230]

Modern JS has String.padStart() and String.padEnd(). Loved the talk, looking forward for more conference stuff from Kevlin Henney!

[@unbekannter_Nutzer]

def fizzbuzz (n: Int) = Seq ("" + n, "Fizz", "Buzz", "FizzBuzz")("300102100120100"(n % 15)-'0') (Scala) For a given n, take its modulo 15, pick the index from the "3001..."-String and return the matching of 4 values from the seq.

[@afterthesmash]

Hilarious: Scala scaled to 3×5. Manager: No, no, no! I meant the 3rd the 5th Mersenne primes, 31 and 8191. You: Oh, lemme quickly check if my Scala compiler supports character literals with 253921 characters inside.

[@afterthesmash]

Shor’s Algorithm for Factoring 15 phasespacecomputing.com/pdf/Product_sheet_Shors.pdf Available in a demonstration kit near you.

[@MarkTomczak]

What impacts does wild card importing have on the performance of one's IDE? Naively, I would expect it requires the IDE to scan all sub packages in the wild card to understand the context of the code. That could have real impact on the performance of the tools you need to write the code. I do a lot of C++, and on a medium sized code base VS code falls over because the #include import system doesn't give the IDE the opportunity to ignore code out of scope.

[@RobertWHurst]

Thanks for the insightful talk. I program Go, Rust, and TypeScript on the regular. I've done plenty of Ruby and Python as well. The knock on JS is a bit much. You don't need to apologize for associating with it. The language has changed and improved a lot since the early Netscape and Internet Exploder (IE6). Also in your fizzbuzz example you used let, you should be using const to declare your variables unless you plan on reassigning them. Other than those minor thoughts, great talk. Thanks for sharing with us :)

[@Yawhatnever]

A quick google search shows that the const keyword was not fully supported in Safari until six months after this talk was uploaded, and in some other browsers it was supported only a few months before the talk was posted.

[@RobertWHurst]

@@Yawhatnever that's fair, but I wouldn't say that's its just a simple search. I hadn't realized this talk was so old, and given that const landed quite a while ago, I think my comment is reasonable given I thought the talk was more recent. But your point absolutely makes sense given timeline. That said I stand by the rest of my comment. Even when this talk came out it was a bit tacky to trash JS as a toy language. It had evolved sufficiently since the Netscape days even then.

[@tissuepaper9962]

@@RobertWHurst *offended JS dev alert!* *offended JS dev alert!* *offended JS dev alert!*

[@RobertWHurst]

@@tissuepaper9962 I'm a polyglot. JS does have plenty of shortcomings. I wouldn't get much of the stuff I work on done if I was limited to a single language. Provincial attitudes about tooling and languages do bother me though - comes from ignorance.

[@tissuepaper9962]

@@RobertWHurst wow, using the word "provincial" in your complaint about ignorance. Do you not see that irony in that? Get bent. I was just poking fun, but now it's clear your head really is up your own ass.

[@whirled_peas]

The point at 57:50 is particularly applicable outwith programming - bad code is everywhere but programmers aren't stupid - blind adherence to ill-applied systems produces stupidity. Ideological possession produces some of the most stupid and wasteful activities there are. Always be on your toes.

[@thomaskaldahl196]

I reserve the comment "This guy is hilarious" for the utmost genius comedians. This guy is hilarious.

[@bobbymorelli9763]

you can avoid checking twice by doing def fizzbuzz(x): return [x,'fizz','buzz','fizzbuzz'][(x%3==0)+(x%5==0)*2]

[@bothieGMX]

The real reason for explicitly naming every single class instead of whole packages is name space pollution. If you do import package a.*; import package b.*; and your code compiles fine, then you only have to wait for version 2 of package 'a' getting released to get a clash of identifiers. And then, nobody remembers, which instance of class Foo you meant. a.Foo or b.Foo? So you can't even resolve this issue without hours of investigation. (Except in the lucky case, you just try a.Foo and it does NOT work, then you know, it was wrong and take b.Foo. But if a.Foo seems to work and b.Foo seems to work too, then you're screwed.)

[@Exilum]

Or whoever updated 'a' checks whether what they did does not cause problems and the problem never existed. Or more than one person is working on it and thus there is versioning, which can easily help you know it was b.Foo you were using. The second is a failsafe for the first, which not doing would literally be considered a grave error. Doing wildcards with exceptions, rather than only explicit naming, is simply just one of the potential better methodologies.

[@ThomasBomb45]

@@Exilum it's good to avoid potential problems even if someone else would be blamed for them if they occur. Especially given that it might not be obvious if something has gone wrong

[@patwilson2546]

In most ways, well written code and testable code are the same thing. Start with the simple mandate that code have tests. You will end up with pretty clean code. Imposing the requirement to test code naturally leads to smaller code elements, code that is structured for a single purpose, code that separates data acquisition from business logic, etc. Making developers responsible for tested code forces them to think about how to test it, which should lead to writing code that can be tested. The same elements that allow easy testing also allow easy reading and understanding.

[@Xiph1980]

Tests should support the code, not the other way around. You are drinking 10 wines.

[@patwilson2546]

​@@Xiph1980 If your resume ever comes across my desk, remind me not to hire you. If you want to learn how to code properly please feel free to read the many treatises on the relationship between tests and production code. In particular, look up the phrase "tests are not second class citizens". Until then, stop dispensing advice on how to develop software. It is obvious that you are no more capable of doing that than I am of suggesting a brain surgery procedure.

[@CYXXYC]

I use comments just as a step-by-step or block separation. Like if you look up some kind of algorithm on wikipedia, there is possibly a list of steps, where each step takes a couple of lines of code. Before each of those lines I'd put a "// 1. ..." comment with a description similar to the one that wiki page suggested. The purpose of it is not explanation of the code, but either paraphrasing in human language (of course you can read complex math and understand it, but I'm pretty sure it's often more comfortable to read the same thing but using words) or just separating steps for clarity - the code itself should in fact also be self-explanatory or just plain readable. Arguably it can be turned into functions, but I usually don't want to pass over 100 parameters instead of just keeping them in scope. As for block separation, its an interesting case since I don't see it done at all. I logically (subjectively) place fields, getters, setters, methods, functions, static data, etc. near each other, and place a triple // above it, separating those parts of code from the others. As an example, the usual approach is to slap all the fields at the very top of the class, and all of the getters at the bottom, even when given a 1000 line file. In my eyes, even a simple "// // Boilerplate //" (newlines omitted) block at the top and placing fields, getters and setters (yeah, Java) nearby should make if not more readable, at least neater looking code.

[@PanduPoluan]

Basically, add comments to help others understand your code, if it's not obvious. Good comments will help you remember why you do things in a particular way when you revisit the code after several months.

[@programaths]

When I did QA, I did search for comments. Those are often a great indication that the code that follow has to be in a dedicated function OR is making assumptions. In the second case, that means tracing the code backward to find out a "boundary" where the assumption has to be checked.

[@kitsunde]

Yeah, no one has time to cover every single border case in every single situation, but you should account for the known considerations or you're asking people to relearn them or infer them from your code. Code comments should be written for the things that the code doesn't explain. I.e. I'm not covering case X, I'm ordering these things in an unusual manner for performance, I'm doing a check here because the nature of this object means we can do an early return in this particular case, we have a usual case to cover because an external client is depending on this implementation. etc. etc.

[@programaths]

@@kitsunde Yep, our commenrs crossed each other. 14h earlier, I wrote that: Comments can be used for WHY, not how. Most languages have systems to document assumptions and even have them checked in debug builds. It's also possible to use comments for code that is not self explanatory, but written that way for performance reasons. One can't assume everyone has the knowledge. One example is the "fast square root" or even if one need to compute some terms in a series.

[@PhillipParr]

I used to be a web developer, but then React happened and everyone's approach to code drove me to insanity.

[@ThatIrritatingGuy]

10:23 the list of tests that the original implementation failed is shown only for a second, making it impossible to read during presentation. If you pause it and actually read the tests, or better yet go back and check the code, you will find that the tests were wrong. If a padding function allows me to pass a multi-character string and I supply it with a multi-character string, I expect that multi-character string to be repeated as padding. Implementation of the presenter takes only the first character, making it incorrect and would make it fail a proper test case. Presenter is being extremely disingenuous.

[@cornholiooooooo]

yeah. i rewinded and stopped for that, too. wtf.

[@forbiddenera]

I actually agree; when reading through the tests I thought that seemed weird; I suppose it depends how you define valid input but I agree with the commenter that if it allows a multiple character input that it should repeat that padding. Perhaps his interest was in dispelling any ambiguity on how multiple character strings are handled; repeating is the obvious choice but not the only answer. What if you passed "$0",3 with the input 12.31 expecting "$00012.31" and got "$0$012.31" or even "$0$0$0$012.31"; padding is generally done with a single character in most cases and perhaps that's why he made the test that way but again I feel like multiple character input in that situation should cause an error or exception..otherwise the behavior should be well defined..accepting and ignoring input is not.

[@forbiddenera]

The 2nd one is interesting too..raises the question: should the pad input be the number of characters to add or the total number of characters required? Again it would depend on your use case, whether you're trying to make all strings a certain length with padding or whether you're just adding padding to the strings. I suppose a good function could do either. If the pad input is negative then that's the number of spaces to add from the left, if is positive than that's the total length of the string

[@jclounge64]

I have to disagree. Firstly the original parameter is called 'ch' which indicates it's expecting a single padding character, and secondly if you pass it more than 1 character then the padding code itself won't work properly in the way someone would expect padding to work. Instead it would produce the wrong number of padding characters all the time, throwing the alignment all over the place.

[@svivs]

7:47 No, I would say the original code is broken. The length parameter is treated as "number of repeats of ch" instead of "final length of the returned string" by the code. In addition, as already noted, ch would indicate a single character. Imagine using this code to populate fields in a database that have a fixed length, you would get overflows and lose data or cause a crash. :)

[@TomaszWiszkowski]

i see all that more frequently than i would wish, yet, as Fernest points out, this really boils down to who authored the code, and how deeply attached people are to their "child" (because come on, if that was just a thing we would not be seeing this. right?) you will see totally bizarre pieces of code addressing undocumented laziness, long forgotten, with no corresponding tests, which nobody can tell why is still needed (it's clear as a day it is needed, but why - is a totally different question). you will see people oblivious to "where you're going" but in authority to tell you "how to get there", frequently sending you the wrong way, but you have to listen or face passive aggressive backlash. this talk is great, but it assumes all engineers are rational. They're not. even in large, established and respected organizations, you will frequently see people who are just too insecure to realize that it is a shared goal to make things better. but hey, this is how the old software dies and gets replaced with a new, better software. resist to improvement is a signal of deterioration and a coming death of a project.

[@brianshacklett9882]

I'm getting flashbacks as he talks about imports. I can't count how many times I've wondered where an identifier is coming from in a Java source file, only to find out that they've used wildcards while importing multiple different frameworks, giving me no point of reference as to what type I'm dealing with. It's absolutely maddening. FWIW, I'm a (Neo)Vim user, and strong advocate of understanding before doing

[@heartbeatpoetry7704]

I do find it useful having all the import statements be explicit. Most of the time it is hidden by the ide and I don't look at it, but when I do want to look at it, it can be very helpful. If you've designed your code well and each file only does 1-2 things, just from looking at the import lines you can get a rough idea of what the file does and how it is doing it. For example if I'm looking at code I've never seen before and I see that in this file it uses a HashMap and a HashSet but no Lists, the set of possible algorithms and implementations that can be in this file is much different from if I see the only java collection being used is List or Vector. This is even more helpful if you are a small cog in a big company which has massive internal libraries and you want to get a quick overview of what possible dependencies you might have to keep in mind when you are looking at a brand new piece of code someone else has written. Uncle Bob's guideline on the wildcard makes sense in a world without ides but with ides, you get the benefits of having the explicit lines without the costs of the clutter and the hassle of manually maintaining them.

[@jackeown]

Darth Vader doesn't say "Luke, I am your father"...but he does say "No, I am your father."

[@neontiger2007]

Who the fuck cares. That joke's so burnt.

[@doggo6517]

Who the fuck names their kid No

[@crowforcast3583]

I have never seen a ballsier tangent than the start of this presentation. Can't believe we're looking into whether warp drives are possible before even starting to talk about programming xD

[@user-jn4sw3iw4h]

38:00 "Luke, I'm your father" A nice example of a proper collapse for SNR reasons. The exact line was never there, but if you were to condense the scene into a single line, it would probably be that one. While it obfuscates, - Why the information was a surprise. - What established information (and source) it reveals to be untrustworthy (both things that are hard to capture in a single clear sentence) It retains, without the 'technical falsehood': - That it was the father, on who's initiative it was shared - That it was a surprise (simply by the fact it is said at all) - That it is a significant plot-point (by the fact it was the summary of the scene (if not the movie) ) It retains, directly due to the 'technical falsehood': - Who we're talking about (within the movie) - Which movie we're talking about. None of which, contradicts the point in the talk about 'the concept of truth', but it is a useful example of another point in it.

[@sabriath]

With the network function, it was like watching reasoning of companies having middle management.....upper management says what they want done, peons at the bottom get it done, middle management literally passes that information on.

[@danielrhouck]

13:36 When I first learned the game, there would be one person in charge who would occasionally add more rules. That can also make it interesting.

[@jeremypnet]

I recommend numbers containing 3 or 5 as a digit have to be fizz or buzz. So 13 is fizz. Also, you have to say fizz or buzz for the divisibility and separately for the digits. So 15 is fizz buzz buzz, 33 is fizz fizz fizz and 35 is fizz fizz buzz buzz. Then there’s fizz buzz whizz which is the same but with 7 also.

[@ysakhno]

"Is too many imports in your code a bad thing?" Depends on whether those imports are actually used or not. Unused imports are a bad thing, and should not be there, period. Otherwise, there is no count of imports that would tip into "too many" area. Usually, it's the other metric signifying so-called 'bad code', that comes into effect first, like too large / to complex a file, etc. The imports are not for _you_ to read, they are needed for the compiler. The alternative would be to spell full class names explicitly each time, or import everything there is to import (via a hypothetical, but thankfully non-existent construct like "import **"). I mean, the rhetorical question in such case is - if one can import the whole package via the star-import, why stop there and not import _all_ the packages at once? If you've spoken to people and nobody could explain to you why use explicit imports, you've spoken to wrong people. That's the only conclusion you should come to. And your conclusion should not be that you're smarter than everybody else and found truth and became enlightened.

[@kefahatumi9095]

Which requirements were used to implement the tests?

[@originuk]

Watched this before, a long time ago, but couldn't remember the title. Found it again, with gratitude. Love the eloquent delivery of words of experience, described with great metaphors. Sensible summarisations and enthusiastic energy! Bonkers World! Love it! Computer science has 2 major problems: 1. Cache Coherency. 2. Naming. 3. Off-by-one errors.

[@BenRangel]

His version of leftpad was hard to read. I don't get the function arguments...What is "pad" are suppose to be. int? string? No turn outs it's a single character. I think the original name "char" was more obvious. Then he stringifies this pad variable and takes the first char from it and assigns that to the pad variable. My first thought was just "what?" I had to read that line many times. I think by overwriting the same variable he's making it much harder to read and losing out on the clarity that a new var name could add. It's much faster to read 4 obvious lines than 1 "clever but quirky" line.

[@timonix2]

It was a wall of text. Might as well have been the opening statement of the Iliad in Greek. The other ones at least tried

[@HadrianusRomanus]

LeftPad function in the Livecode language is much easier to write and understand: function leftPad tText, tLen, tPad repeat while the length of tText < tLen put tPad before tText end repeat return tText end leftPad

[@HadrianusRomanus]

My comment was about kzbin.info/www/bejne/fKqmiqmXbqmbqas

[@0MVR_0]

At first import as normal. Then select for the necessary external methods, rewriting any algorithms that can be done 'by-hand' or use only a single dependency package. A code illegible is a similar to an archeologist finding an indecipherable artifact, yet the complexity is rarely of length, and rather gratuitous shorthand.

[@Jollyprez]

The issue, really, is maintenance. 80% of all software engineering is maintenance. I've had to maintain my own code for literally decades. In pure self-defense I have developed a way of coding that I can go back to after a decade and still understand what is going on. Also, in my case, I consistently use the simplest coding possible. This means that I tend to avoid using language-specific special syntax when a more common syntax will work. I imagine that I would fail some javascript tests because I don't find it necessary to use '=>' and I avoid 12-part ORs inside an if or whathaveyou. As a result, my code, while maybe "old-fashioned" is usually only about 25% of the size of just about any other programmer's code I've ever seen. And, yes, I've done some seriously complex stuff. When asked a few years ago by a UI designer for my guidance on what a very complicated UI could look like - I told him that if he could draw it, I could code it - AND - make it responsive. He was flabbergasted. But, he did it, and so did I. And the code was tiny.