this post was submitted on 19 Feb 2024
39 points (95.3% liked)

Programming

17504 readers
19 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

I'm just generalizing, like if you want to copy some cleaver feature or modify some Python program you came across, what are the red or green flags indicating how well your (or particularly some hobbyist's/your early learning self's) results are likely to turn out?

Also how can you tell when reading into such a project is going to be a major project that is beyond the scope of you ultimate goals. For instance, I wanted to modify Merlin 3d printer firmware for hardware that was not already present in the project, but as an Arduino copy pasta hobbyist, despite my best efforts, that was simply too much for me to tackle at the time because of the complexity of the code base and my limited skills.

How do you learn to spot these situations before diving down the rabbit hole? Or, to put it another way, what advice would you give yourself at this stage of the learning curve?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] RonSijm 10 points 9 months ago* (last edited 9 months ago) (3 children)

Generally mostly by cyclomatic complexity:

  • How big are the methods overall

  • Do methods have a somewhat single responsibility

  • How is the structure, is everything inner-connected and calling each other, or are there some levels of orchestration?

  • Do they have any basic unittests, so that if I want to add anything, I can copypaste some test with an entrypoint close to my modifation to see how things are going

  • Bonus: they actually have linter configuration in their project, and consistent commonly used style guidelines

If the code-structure itself is good, but the formatting is bad, I can generally just run the code though a linter that fixes all the formatting. That makes it easier to use, but probably not something I'd actually contribute PRs to

How do you learn to spot these situations before diving down the rabbit hole? Or, to put it another way, what advice would you give yourself at this stage of the learning curve?

Probably some kind of metric of "If I open this code in an IDE, and add my modification, how long will it take before I can find a suitable entrypoint, and how long before I can test my changes" - if it's like half a day of debugging and diagnostics before I even can get started trying to change anything, it's seems a bit tedious

Edit: Though also, how much time is this going to save you if you do implement it? If it saves you weeks of work once you have this feature, but it takes a couple of days, I suppose it's worth going though some tedious stuff.

But then again: I'd also check: are there other similar libraries with "higher scoring" "changeability metrics"

So in your specific case:

I wanted to modify Merlin 3d printer firmware

Is there any test with a mocked 3d printer to test this, or is this a case of compiling a custom framework, installing it on your actual printer, potentially bricking it if the framework is broken - etc etc

[โ€“] HamsterRage 2 points 9 months ago* (last edited 9 months ago)

For me, it's mostly Java and Kotlin. I look for the same kind of things. Things that I like to see:

  • Short methods.
  • Small classes
  • Sensible packages
  • Variables declared to Interfaces not implementations
  • Single Responsibility Principle applied.
  • DRY applied.
  • Good names for variables and methods
  • Few instance variables
  • Few static members
  • No comments, because you don't need them
  • Uses lambdas, Streams and Optional
  • No empty Catch{} blocks
  • No f*&^*cking! arrays.

I can generally tell in a few minutes if something is going to be a pain to work with.

load more comments (2 replies)