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

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.

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

@@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.

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...

Agreed!

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

@@mfaizsyahmi you need to try in order to catch

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

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

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

@@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.

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.

@@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.

@@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.

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

The indentations are making me so uncomfortable

@@herp_derpingson i like them

@@youssef2366 found the python guy

@@nicholascarson5509 I actually do use python lmao

Very true, two different skills, both necessary.

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

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

@@charlestaylor9424 you've met my teachers

sad programmer noises.

LOL

That's what virtualization and load balancing are for.

😀

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

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

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

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.

@@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.

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.

@@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.

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.

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

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

@@Thatoneguy-o7805 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.

@@Thatoneguy-o7805 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.

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

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.

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.

@@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.

​@@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.

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

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

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

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.

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".

so, bash?

@@ishdx9374 snobol

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.

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

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.

@@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.

​@@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

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

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

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.

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.

​@@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.

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

Those darn defaults are always wrong.

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

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

+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.

agreed

@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,...

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.

I code only for myself and I think EXACTLY this

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.

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

Me too lol

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

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.

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 …

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.)

@@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.)

junit vs junit.jupiter

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

@@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.

@@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.

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....

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

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

@@pt8306 an empty collection could be a singleton.

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

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

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.

@@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! :)

@@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.

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).

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

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...

I had to stop watching.

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

@@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.

@@casperes0912 45:30 the cards are really ironic

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)

@@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.

@@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.

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

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

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.

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

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.

@@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.

Was kinda 60 minutes early with that one 🤣

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.

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

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.

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

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.

@@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...

@@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.

@@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.

@@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).

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.

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

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

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

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

Agreed

Thenceforth it shall be used again.

Did it ever leave?

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.

@@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.

@@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.

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

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

@@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.

#define QUESTION (bb || !bb)

@@manonthedollar #define QUESTION (true)

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

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

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

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.

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

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.

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. :)

"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.

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.

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)

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

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

​@@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.

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

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.

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.

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.

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

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.

@@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

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.

@@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.

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

@@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.

@@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.

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

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

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.

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.

@@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.

-1 dB

Depends on your definitions of signal and noise. If this is noise, I quite like the noise.

The stuff that wasn't informative was entertaining. I appreciated it.

1.1. Collisions are actually a pretty negligible problem. If your library doesn't collide with your other libraries, there are little chances it does in the future. 1.2. Nothing stops you from only doing partial imports on one of the colliding libraries. You can use wildcards for 99% of your imported classes, and just have that one outlier be imported specifically. That's still way cleaner. 1.3. Any maintained library will go through a deprecation phase. You know your classes or the part of the class your are using is going to be deprecated long before the version it actually stops working at. 1.4. Whether you imported the class individually or not, you are still warned in the same way about said deprecation, and you still have to change your code the same way, the only thing that changes is that you don't need to change the imports in the case of a wildcard, just switch to the newer library. 2.1. You DO NOT need to tell where a name comes from. You need to tell what a name does, and is used for. This is what naming is for in the first place. 2.2. With an IDE, you can hover your mouse over the name and see where it comes from, and eventual additional comments. Without an IDE, the library name would have been less specific and thus wouldn't have helped you knowing what the name does more than it already does. 2.3. Non-wildcard imports do not make life easier for readers, it's an illusion. By having more information, you think you know more, but you have duplicate infos. These imports give you general information that should already either be specified in the names you use, either by the way they are used. 2.4. And that's with an IDE, if you're looking to read code without an IDE, you'd need more time to figure out which one of the 100 or so lines concerns your one piece of code than to just read it anyway. You'd need not only to text search one way, but also do so the other way to find back your code. And in the end, you wouldn't have gotten more information than you already had. If it's a library you knew, you already knew it, if it isn't, you won't know it, and the name is more descriptive in both cases.

No

fizzbuzz = (n) => [["fizzbuzz", "fizz"],["buzz",n]][n%3?1:0][n%5?1:0] FUCK Javascript :@

@SArpnt Did you test your "more accurate" version? > Uncaught TypeError: Cannot read property 'false' of undefined

That's pretty good!

@SArpnt Don't worry, you can write fizzbuzz = n => [["fizzbuzz", "fizz"], ["buzz", n]][+!!(n % 3)][+!!(n % 5)]

sorry just gotta flex on 'ya fizzbuzz = lambda n:[str(n),'fizz','buzz','fizzbuzz'][(not n%3) + (not n%5)*2]

Hmm, an interesting justification. Thanks for the insight

So your explanation puts an emphasis on how mindlessly people merge two codebases. In other words, if we imagine the two wildly different domains -- the one that is about the mindfulness of the software engineers that are doing the merge, and the other that is the technical and cognitive state of the product of software engineering -- you're brazenly mixing between the two with the idea that it's the same thing, which they are not. Your solution doesn't change or correct the irresponsible malice of the social/labor domain of codebase merging (which is effectively producing a new codebase without exception), it merely prevents the potentially catastrophic outcome by chance, by employing an unnecessary and opaque safeguard that further complicates the cognitive structure of the product (i.e. readability), encourages further boilerplate, and does that mostly for conspiratorial, superstitious, and particularly defensive cross-domain reasons. That's a hidden accident waiting to happen, while you're doing nothing to eradicate the root causes. In fact, I'd immediately fire you for remedying a cross-domain problem like that, because you're hiding the actual cause of any potential situation, and are diluting the responsibility of the action. You're basically breeding a dragon. If that's not a term, it should be. It's a particularly vicious type of dragon, one >>you thought

@@milanstevic8424 Heh, it's hard to take you seriously when this is something you'd fire me for. "I made things harder for you and still you made an error? You're fired!", or if this idea is taken to a more extreme level: "Let's not write tests so my programmers will be more responsible!" Nah I don't buy it. Trust me that my team is much better off when they focus on more interesting problems to solve. Considering the size of merges (or rebases, whatever workflow takes your fancy), you don't need large codebase merges for this particular accident to happen. We've been using continuous integration for years, and it still happened to us once. Those merges weren't hard, and we did them carefully. It can occur already when whitespace conflicts are resolved incorrectly (if no braces are used). Considering readability, this is the first time I've heard somebody call two braces 'boilerplate'. I wonder what you think then of Pascal's _begin_ and _end_ keywords. You also had the opportunity to suggest an alternative: put the 'then' clause on the same line as the if-condition: ```if (condition) DoSomething();``` No extra braces, no merge problems, even more condensed code. Best of all worlds. Responsible programmers learn responsible habits. I consider usage of braces one of them. For the record, please don't insult me by saying I'm doing cargo cult programming, or using defensive programming without reason. I didn't take offense, but you don't know who you're talking to.

@@PuzzleQodec I never called two braces boilerplate. I said that the two braces invite boilerplate and abnormal cluttering. Which they do. The thing is, if you don't actually need the two braces, then you don't need the two braces. Placing them everywhere makes every little bit of code lovingly compatible for a few more lines to be quickly added by your colleagues that are likely to be less than enthusiastic about finding or inventing a proper place for them. This goes out of hand quickly and invites further boilerplate. "Responsible programmers learn responsible habits." There is a massive contradiction lurking beneath this quote. There are no good habits in programming. Literally none of the habits are good, let alone responsible. You also don't need habits to be a good programmer. And no business wants its programmers to be run by habits. If you're thinking like "hygienic habits" like washing your hands after visiting the restroom, that is exactly what is known as a boilerplate, and we need less of it in code, not more. Maybe it's good for you (or your management) because you strain less and appear to do more work with less energy, but that's not exactly desirable if you ask me. Maybe it is desirable for you, but if you're on cruise-control 24/7, never checking your assumptions and never trying to figure out the non-habitual ways of doing things, I'm sorry but you're not a great programmer. I seriously don't want to know in which company you're applying that attitude. "I didn't take offense, but you don't know who you're talking to." Of course you didn't take any offense, because I didn't offend. I can state the latter part just as easily and with greater authority, but why does that matter? Please don't venture into argumentative fallacies. I have concretely criticized your approach in how you're theoretically handling a multi-domain problem, in a non-offensive manner, while you haven't even addressed what I said. Yes, I would fire you big time for doing that. You're basically acting all smart without understanding the eventual consequences that are typical for such an irresponsible behavior. You're OPTIMIZING early, you're saving someone's ass to save your own production line, you're covering up a mistake that SHOULD go off, because then a better practice and a better convention could be invented. All in all, you're just following the unspoken rules of your management, who practically can't discern between a poor merge and poor implementation, which is also typical, and you've learned to covering it all up, only to make things run smoothly. That whole concept needs to go away, can you understand that? If your management is idiotic, the company SHOULD suffer from their appalling practices and poor understanding of how things work. And you, on the other hand, if you're an engineer, should focus instead on how to have the cleanest possible code, completely free of habits, superstition, and clutter, while providing its users maximum experience. You're basically committing a fraud by thinking that your solution is for a greater good. Everything appears shiny from the outside, but you're invisibly bloating the codebase and cramming it up with unnecessary symbols that cumulatively make the code harder and harder to understand, with an excuse that it "saves lives" and money in the long run. After a certain point, and this is bound to happen sooner than later, trivial things/methods/routines become very labor-intensive to read and maintain, and it's NO ONE's fault. Not even yours. It's "how we run things, that's normal, no problem in that".. So very much like that Java import situation from the video, which is a ridiculous real world example. Finally, you're the only one who can navigate this two-brace labyrinth of your doing, because you've trained yourself against such malpractices for years, artificially making you irreplaceable in your organization. Everything is enveloped in two braces, has 16 indentations, null checks all over the place, funny-looking imports, multi-lined function calls, and whatnot, and voila you have created a symbolic culture that a beginner (however proficient he or she might be with the language itself) can't decipher without earning rites of initiation in your company FOR YEARS. Do you get where your problem lies? It's as much social as it is technical. I think I've thoroughly explained why I think you're wrong and why you shouldn't go through that red light even if there is no traffic on the intersection. Don't play smart. I'd fire you twice if I could. So instead of being offended, try to learn something out of it, and stay happy because you're obviously working for crappy companies that seem to pay attention someplace else instead of where their money and reputation actually lives.

@@milanstevic8424 Sorry, I think you're only arguing for the sake of it. I'll stop wasting my time.