All good code is alike; bad code is bad in its own way. -- Leo Tolstoy
The code I'm working with is bad in that I'm having to dig though hundreds of global of questionable necessity, and functions like modify_all_variables() that's ALL side-effects, so that it's hard to know what the behavior actually is, much less modify or replace it.
The lack of modularity and proper abstractions makes it hard to modify. Is it bad "editability" (inventing the word in the same vein as "readability")?
I think there's more to it than that. For example I try to keep subroutines to where I can see everything they do in one screen, and while that used to be 24 rows by 80 columns (standard VT100 terminal size, back in the day), for VSCode on a HD monitor, I'm running 55x90 or so. Even fairly straightforward code can be hard to track if it's into the KLOCs without structure.
In my case, with modify_all_variables(), I don't know what's in it, I have once found where it is (I don't believe it's in the program at hand) and I would have been much happier to see var new_vals = modify_all_vars(old_vals), as this cuts the scope to what's being modified to new_vals and old_vals, giving me much less to fit into my head.
So, yes, I guess, although that "lost" feeling comes more when I'm very full-stack, leaping a lot from CSS to HTML to JS to backend code (in my case, Perl) to SQL to Bash and back and forth a lot. I swear, there have been days when I could not pull together a complete sentence after that bulldada, but this is less bad code than all eggs in my basket.
("Editability" has past usage at least as far as 2009, and while it may not be in Webster's, anyone who understands read -> readable -> readability should be able to get editability, so we should start lobbying the OED.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
All good code is alike; bad code is bad in its own way. -- Leo Tolstoy
The code I'm working with is bad in that I'm having to dig though hundreds of global of questionable necessity, and functions like
modify_all_variables()
that's ALL side-effects, so that it's hard to know what the behavior actually is, much less modify or replace it.But there are many other ways to have bad code.
The quote 😂
A lot off side effects in one function, means that it is hard to "load" the code in the head, right?
. source
The lack of modularity and proper abstractions makes it hard to modify. Is it bad "editability" (inventing the word in the same vein as "readability")?
I always ❤ MonkeyUser.
I think there's more to it than that. For example I try to keep subroutines to where I can see everything they do in one screen, and while that used to be 24 rows by 80 columns (standard VT100 terminal size, back in the day), for VSCode on a HD monitor, I'm running 55x90 or so. Even fairly straightforward code can be hard to track if it's into the KLOCs without structure.
In my case, with
modify_all_variables()
, I don't know what's in it, I have once found where it is (I don't believe it's in the program at hand) and I would have been much happier to seevar new_vals = modify_all_vars(old_vals)
, as this cuts the scope to what's being modified tonew_vals
andold_vals
, giving me much less to fit into my head.So, yes, I guess, although that "lost" feeling comes more when I'm very full-stack, leaping a lot from CSS to HTML to JS to backend code (in my case, Perl) to SQL to Bash and back and forth a lot. I swear, there have been days when I could not pull together a complete sentence after that bulldada, but this is less bad code than all eggs in my basket.
("Editability" has past usage at least as far as 2009, and while it may not be in Webster's, anyone who understands read -> readable -> readability should be able to get editability, so we should start lobbying the OED.)