#refactoring

[e8luhs]

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

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

[elysiuminfra]

DIGITAL VIOLENCE, DIGITAL WORLD

( guys by @e8luhs​ )

textless :]

[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!

[dontcode]

I think my commit name is very funny

[mysteriekiss]

👍

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

[daniiltkachev]

Clean code in practice: best practices and tools for PHP developers

Learn how to write clean, maintainable PHP code with practical tips, refactoring techniques, and essential tools to improve readability and efficiency.Clean code is the foundation of maintainable and scalable software. This guide explores best practices, tools, and techniques for PHP developers to write cleaner, more efficient code.What is clean code and why does it matter?Clean code is more than just a buzzword; it's a philosophy that emphasizes readability, simplicity, and maintainability. Writing clean code ensures that your software is easy to understand, modify, and extend, which is crucial for long-term success. In PHP development, clean code practices can significantly reduce technical debt and improve team collaboration.Consider the following example of poorly written PHP code:function processData($data) { $result = ; foreach ($data as $item) { if ($item == 'active') { $result = $item; } } return $result; }While this code works, it lacks clarity and can be improved. Here's a cleaner version:function filterActiveItems(array $data): array { return array_filter($data, fn($item) => $item === 'active'); }The second version is more concise, uses modern PHP features, and clearly communicates its purpose.Key principles of clean codeTo write clean code, follow these principles:- Readability: Code should be easy to read and understand. Use meaningful variable and function names. - Simplicity: Avoid unnecessary complexity. Break down large functions into smaller, reusable ones. - Maintainability: Write code that is easy to modify and extend. Follow consistent coding standards.For example, instead of writing a monolithic function, break it into smaller, focused functions:function calculateOrderTotal(array $items): float { $subtotal = calculateSubtotal($items); $tax = calculateTax($subtotal); return $subtotal + $tax; }Tools for enforcing clean codeSeveral tools can help PHP developers maintain clean code:- PHP_CodeSniffer: Detects violations of coding standards. - PHPStan: A static analysis tool that finds bugs and improves code quality. - PHP-CS-Fixer: Automatically fixes coding standard issues. - Extract Method: Break down large functions into smaller ones. - Rename Variables: Use descriptive names to improve readability. - Remove Duplication: Identify and eliminate repetitive code.For example, refactor this code:function calculateTotal($items) { $total = 0; foreach ($items as $item) { $total += $item * $item; } return $total; }Into this:function calculateTotal(array $items): float { return array_reduce($items, fn($total, $item) => $total + ($item * $item), 0); }This refactored version is more concise and leverages PHP's functional programming features.Common pitfalls to avoidEven experienced developers can fall into traps that lead to messy code. Avoid these common mistakes:- Over-engineering: Adding unnecessary complexity to solve simple problems. - Ignoring coding standards: Inconsistent formatting makes code harder to read. - Neglecting documentation: Clear comments and documentation are essential for maintainability.By following these best practices and using the right tools, PHP developers can write clean, efficient, and maintainable code that stands the test of time. Read the full article

[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

[e8luhs]

YOU'RE A BIT COMBUSTIBLE, DON'T BREAK MY HEART

[elysiuminfra]

vladimir kaiser fancam

[frog707]

See eye

I've been making slow progress on Lesson 24 of the Vulkan tutorial ("Images"). Some of the time has been spent deciding between two approaches for loading images: Java's Abstract Window Toolkit or LWJGL's STB library? (In the end, I decided to use AWT because it works with Java streams.) Some of the delay has been caused by distractions, both software-related (Gradle v8.2.1) and otherwise. Also there were bugs in my code, but unfortunately not the sort of bugs that make interesting war stories.

Instead of blogging about what I did and didn't do this week, I'll highlight a small (but important) milestone from last week: setting up continuous integration (CI) at GitHub. (That was commit 3881b184, in case you're following along.)

Continuous integration is a very simple idea: each time you submit a change, it gets integrated immediately, and the entire project gets built in a stable environment, with prompt notification in case the build fails.

"But surely," you think, "An experienced coder like frog707 rebuilds his project for every commit, let alone every push!"

It's true, I rebuild more often than I commit, but only in my dev environment (currently Java 17 on Windows 11). And more importantly, the project I'm building might not match what's in the public repo at GitHub. That's because I follow a relaxed coding style, which means sometimes I have multiple changes in progress at once. For instance, while working on adding a major feature, I might notice some valuable refactoring that needs doing. Rather than waiting until the feature is done, I refactor while the idea is fresh in my mind. The feature and the refactor will of course end up in separate commits, and it's quite possible I'll push them to the public repo separately, or even days apart. That's one way I can break the public repo without realizing it. CI lets me know I screwed up, so I can correct promptly.

Another boo-boo that CI catches for me is when I push changes that build on one platform or Java version but not another.

CI becomes even more important when I'm working as part of a team. In team projects, "breaking the build" might mean that nobody can submit changes, and that's a major disruption!

[jacelynsia]

Is your code hard to understand or maintain?

Learn about code refactoring and discover techniques, tools, and best practices to: - Improve code readability & maintainability - Increase code efficiency and reusability ️ - Reduce technical debt Read our blog post to become a code refactoring pro! 

[technology-and-beyond]

How modernizing or updating legacy IT or monolithic systems can help companies?

Learn how modernizing legacy IT systems enhances efficiency, security, and scalability while reducing costs. It fosters business agility, staff productivity, and customer experience, allowing for the integration of new technologies and features.

[asadmukhtarr]

"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, also known as Uncle Bob, is a foundational book for software developers aiming to write high-quality, maintainable, and efficient code. The book emphasizes the importance of writing clean code and provides practical guidelines and best practices to achieve it. Below is a user-friendly, step-by-step breakdown of the key outcomes and takeaways from the book, designed to help developers improve their coding practices.