#Refactoring

[e8luhs]

RED WIRE / BLUE WIRE

[frog707]

Slimming down

Like all software metrics, "lines of code" shouldn't be applied blindly.

Today my software WIP's LoC metric is rapidly declining because I've created C++ macros to generate boilerplate code. I'm talking code I used to copy and paste every time I needed it.

This is the kind of refactoring I love, because it means less code to maintain in the future. Fewer chances for coding errors. Less scrolling through source code to find the interesting parts.

And in this case, I believe it also uncovered (and solved) a bug. So a big win all around.

But from a strict "lines of code" perspective, this would be considered a step backward.

[elysiuminfra]

vladimir kaiser fancam

[dontcode]

I think my commit name is very funny

[mysteriekiss]

👍

[sucka99]

[asadmukhtarr]

"Working Effectively with Legacy Code" by Michael C. Feathers is a must-read for developers and software engineers who deal with legacy systems. Legacy code, often characterized by its complexity, lack of documentation, and resistance to change, can be daunting to work with. This book provides practical strategies and techniques to understand, refactor, and improve legacy codebases. Below is a user-friendly, step-by-step breakdown of the key outcomes and takeaways from the book.

[e8luhs]

electra leart (lea heart). or something. i dont know

just lea w/o the text or background under the cut:

[frog707]

refactoring

I lied when I said I was going to work next on loading a 3-D model. Sorry, old habit! Actually, I went straight into refactoring. Let me explain...

The English Wikipedia defines refactoring as "the process of restructuring existing computer code . . . without changing its external behavior", which is fairly accurate, though lacking in motivation.

My back-of-mind definition would be "changes to code whose primary purpose is not to add features or solve issues, but to make the codebase easier to maintain".

Back when I worked for corporations, I got in the habit of never mentioning refactoring around anyone who wasn't a software developer. If my boss (or my boss's boss) knew I was making changes (and spending work hours) on something other than approved features or known issues, awkward questions would arise. (Like, do we have a billing code for that?)

Anyone who's worked intimately with a large software project knows that if changes are made only for features and issues, the project will accumulate "technical debt" that makes it difficult to maintain: hard to explain/learn/understand/remember how it works and hard to make changes without introducing bugs.

Both of today's refactorings focussed on the BaseApplication class, which became unwieldy weeks ago. Last night the source file for the class reached 1901 lines of Java code (not counting blanks, comments, and javadoc). I don't place a hard limit on lines of code in a class, but a file containing 1901 LoCs positively screams technical debt. It's especially painful these days, since I'm working on a laptop with a tiny screen and using a track pad instead of a mouse. (I spend lots of time scrolling back and forth, hunting for the lines I need to change.) Cramming as much as possible into a single file makes some sense for a tutorial, but I see the V-Sport project as something I'll be maintaining for many years.

First I split off all the code that deals with physical devices and put that in a new PhysicalDevice class. The change greatly clarified which properties of the physical device matter and how that information is accessed.

Then I split off all the code that deals with texture data into a new Texture class. The new class bundles up 3 related Vulkan resources and provides a clear lifecycle of create/use/destroy. I expect it to minimize duplication of code when the project transitions (sometime in the near future) from a single texture to multiple textures.

I'm subjectively pleased with how smoothly today's refactoring went. One measure of its success is that BaseApplication shrank from 1901 to 1650 lines of code. Still plenty of room for improvement, though!

[elysiuminfra]

ive been working on this storyboard project for a while. it's as finished as it's going to get. please enjoy

[jonfazzaro]

"Don't be afraid to refactor code to use the right data representation—the type system will ensure you've covered all the places that need changing, and it will likely save you a headache later."

[guzsdaily]

Simplicity in the complexity

Day 171 - Apr 24th, 12.024

I started to notice something new while programming in Rust after a while, that I don't know if it is normal for this language learning curve or not.

There's a problem that I had for a long time, and still have sometimes, that it is premature optimization, in other words, I try to make code that will last for days, weeks, months, years too early in the project. This is a normal problem, however, I feel like having anxiety really worse this problem in the level that I end up trying to find a "correct/perfect" solution on the first or second try, trying to build the whole feature on one go. And of course, it never works, and I have to end up rewrite more code than I should.

So then enters Rust. Rust is a complex language and somewhat difficult to be clever with, even more if you're trying to be "correctly clever", and because of things like the borrow checker, I personally can't write a snippet of code without any borrow errors appearing that I need to go back and tweak them to work. Because of this difficulty, I started to notice that I am prototyping a lot more than before, making code that I know isn't scalable or clean, to first find a satisfying solution, and then refactor into a more organized and readable way. It is like the language forces me to first experiment with it, to then find a clear solution and rewrite it. The entire .mdparser project is working this way, having pretty much rewritten most of the original code for it now that I know the problem and language better. It is being an interesting learning experience.

Also, just because I liked the way it looked, this is the progress of one of the codes that I wrote this day (it is a section of the conversion from a Markdown AST to a Tumblr's Neue Post Format AST):

The first iteration where I was able to convert it.

Getting the main steps of the conversion and splitting them into functions and methods:

And a small change to the BlockText object to simplify even more:

I know that this isn't the best code in the world, but it is a improvement from the first iteration, and hopefully I can improve it in the following days.

Today's artists & creative things Music: DECO*27 - ラビットホール feat. 初音ミク / GuitarCover🍁 - by かえで // kaede🍁

© 2024 Gustavo "Guz" L. de Mello. Licensed under CC BY-SA 4.0