Reviewing your Code: Refactoring

drum roll for the outro, side by side of the two source code samples, bummer, the editor signed out.
super nice either ways

is this lisa virus? or .iisa virus?

question, what is the best way to organize your code, especially libraries, where they make intuitive sense? grouping by function/functional area?

When you removed the static keyword(s), the values of those local variables became undefined. (Static vars will be initialised to 0)... Fortunately, this code didn't rely on the explicit 'static' nature of those vars...

MAX_PATH is MAX_PATH... When descending into a child directory, it would be better (imo) to tack the child's name (and '/' of course) onto the end of the current path buffer, then simply truncate (restore the '\0') when that recursive call returns. No need for malloc (that can fail) or forgetting to free()... (Don't overflow that single string buffer, of course!)

Oh! And!! Move the workhorse function ahead of its invocation and lose the maintenance overhead of changing both the function definition and its prototype declaration when parameters need changing... Fewer lines of code = less chance for errors to creep in...

I’d like a version of this code using functions instead of comments

More if this please, loved this.

That macro is so useful. Thanks for the videos!

should you use "ruby" for testing? couldn't a bash script do that? do we need to learn lots of languages when common languages can do the required work?

Most of the choices made here were good and intuitive, but I'm not a big fan of removing the no arguments version. Given that the program is called lsa, I'd want to keep the behavior as close to ls as possible. Since you can invoke ls without arguments, it's probably going to cause problems when you have a similarly named offshoot tool that works differently.

More videos about refactoring and code reviews in this code smell series

You're welcome to be wrong haha.

would be great if you could make one of these for tests in C!

Great video! I'm not sure if having lsa3 handle only one argument is the only way to make it better/more maintainable. You could, for instance, validate the args ahead of time, checking if they exist, inserting a default "." if no arg exists, etc. And then passing the validated args to the main function

hey jacob, thnks for the awesome videos firstly.
Also, can you create a video about atomic operations in C. Like a lot of confusing types like _Atomic and strange functions like atomic_compare_exchange_strong_explicit etc. Also if possible do you know any atomic double compare and swap ways?

Just curious...is there any advantage to using the macros over the stdlib assert? Other than the custom message?

"Can I get some pointers for cleaner code?"

"Sure: 0x7fffd0ff7eec, 0x7fffd0ff7ee8, 0x7fffd0ff7ee4"

Your videos are very informative and well-structured, keep up the good work

Would love to get info on automating tests.

Great review! I love the error checking macros in particular, I hadn’t thought of that before! Smaller code footprint makes me happy.

I think location of declared variables will always be up to preference. Personally I declare variables just before where they will be used, and (where appropriate, eg temporary storage in a loop) in the most limited scope possible. Nothing gets me more confused in code than hopping between the body of the function and variable declarations at the top to see the type of some system call related struct for example. Can’t always use this philosophy with legacy code/compilers, but I’m fortunate enough to be working with C99 :)