Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.
Programming
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 !webdev@programming.dev
Only if the code base is well tested.
Edit: always add tests when you change code that doesn’t have tests.
Been with a lot of codebases that had no unit tests at all and everyone was afraid to change anything because the QA process could take weeks to months.
The result is you have a codebase that ages like milk.
Doesn't everybody agree with this? I really never thought of it as a hot take.
I highly doubt most corps do
Internet would be better if javascript was never invented.
The JavaScript ecosystem is made worse by the legions of "developers" in it which amount to bro-velopers that put no thought into if something is needed before they create it. There's a strong overlap between the idiots in crypto and JavaScript developers that needs to be decoupled drastically.
Python is legitimately the best language by far for the vast majority of non-performance critical tasks, and most tasks that need to be developed for are not performance critical.
This is the only way;
if (condition) {
code
}
Not
if (condition)
{
code
}
Also because of my dyslexia I prefer variable & function names like this; 'File_Acces' I find it easier to read than 'fileAcces'
My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.
After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.
Until you know a few very different languages, you don't know what a good language is, so just relax on having opinions about which languages are better. You don't need those opinions. They just get in your way.
Don't even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined ... but that was wrong. JavaScript is fine, C# is fine ... as long as you don't stop there.
(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney's first published game, back when Epic Games was called Potomac Computer Systems. It doesn't have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn't cause brain damage, no language will.)
Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me". So what if the first language you used required curly braces, and the next one you learn doesn't? So what if type inference means that you don't have to write int on your ints? You'll get used to it.
You learned how to use curly braces, and you'll learn how to use something else too. You're smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are "unintuitive" rather than merely temporarily unfamiliar is just getting in your way.
Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me"...The idea that some features are "unintuitive" rather than merely temporarily unfamiliar is just getting in your way.
Well i mean... that's kinda what "unintuitive" means. Intuitive, i.e. natural/obvious/without effort. Having to gain familiarity sorta literally means it's not that, thus unintuitive.
I dont disagree with your sentiment, but these people are using the correct term. For example, python len(object) instead of obj.len() trips me up to this day because 99% of the time i think [thing] -> [action], and most language constructs encourage that. If I still regularly type an object name, and then have to scroll the cursor back over and type "len(", i cant possibly be using my intuition. It's not the language's "fault" - because it's not really "wrong" - but it is unintuitive.
No programming language is “natural/obvious/without effort”.
You could say that about anything. Of course you have to learn something the first time and it's "unintuitive" then. Intuition is literally an expectation based on prior experience.
Intuitive patterns exist in programming languages. For example, most conditionals are denoted with "if", "else", and "while". You would find it intuitive if a new programming language adhered to that. You'd find it unintuitive if the conditionals were denoted with "dnwwkcoeo", "wowpekg cneo", and "coebemal".
I really love the project structure of C++. I know that it is an archaic design developed like this due to lack of resources, but I find packages extremely offputting.
The first reason is that splitting declaration and implementation across files makes it easier to figure out what something does.
Second reason is that I feel that I have more control over libraries and packages that have to be manually added to a project rather than using a package manager.
Third, I feel like modern languages iterate over too many versions too fast. C++ has version releases too, but I feel that versioning is handled better from time, compatibility and stability point of view.
Python is only good for short programs
Shorter code is almost always better.
Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.
A nice thing about code length is it's objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.
It takes a damn good abstraction to beat having shorter code.
I mostly agree with this but more than shorter code I value readability, I would rather take 3 lines to be clear to any developer than use some obscure or easy to misunderstand structure to write it in 1.
Yep. And three functions is better than one for legibility even if one would be fewer lines of code
Using single character variable names is always bad practice
Except i right? Something like counter or index seems unconventional and unnecessarily verbose
JS is horse shit. Instead of trying to improve it or using that high level scripting language as a compilation target (wtf?!), we should deprecate it entirely and put all efforts into web assembly.
That the entire industry is cyclical and the current trends are yesterday's anarcisms. Oop Vs functional, separating concerns Vs vertical slices, there's examples all over the place.
All of this has happened before and all of this will happen again.
Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.
Its ok to have more advanced topic that require more knowledge and that people don't understand from the first moment they see them.
As an embedded firmware guy for 10ish years:
C can die in a fire. It's "simplicity" hides the emergent complexity by using it as it has nearly no compile time checks for anything and nearly no potential for sensible abstraction. It's like walking on an infinite tight rope in fog while an earth quake is happening.
For completely different reasons: The same is true for C++ but to a far lesser extent.
Microsoft has not made a good product. Ever. Every program has issues that should not be there if you're selling it. Yet they get away with it
typescript? i know its a bandaid on a severed leg at this point but still
Someone didn’t own a Zune and it shows.
Duplicate code can be a code smell, but it's far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.
See Write Everything Twice (WET) principle.
Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It's like the assembly of type systems, except it makes your program slower instead of faster.
Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.
If you don't add comments, even rudimentary ones, or you don't use a naming convention that accurately describes the variables or the functions, you're a bad programmer. It doesn't matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you're doing an decipher it.
However, engineers who rely solely on comments to explain their code, are bad at writing readable code.
Self documenting code is infinitely more valuable than comments because then code spreads with it's use, whereas the comments stay behind.
I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.
One of the things I tell my juniors is, "this isn't the 80s. There isn't an 80 character line limit. The computer doesn't benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code."
There's no such thing as self documenting code, unless every method and variable name has the word "because" in it.
Anyone can read what the code does. The comments are there to answer why it does what it does the way it does.
Why is invariably lost to time, if it's not committed to a comment here and there.
Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There's a certain kind of dev that just gets a superiority complex about using CLI stuff.
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
- The terminal can remember everything you ever did. Forgotten the command you wrote 2 months ago? You can do a search for it with a tool like
fzfand run the exact same command again. - Communicating with others. GUI programs require step by step instructions, often accompanied by screenshots while CLI may be copy/pasted.
- Combining programs together. There are a few different techniques for combining CLI programs to search/format output, use secrets without ever having them in the clipboard or on disk, monitor something frequently/constantly etc etc
So while I agree with you that there's plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
Just no. CLI can be automated, which makes it superior. It's not a superiority complex, it's a fact. I'm not a minimal wage worker pushing buttons I don't understand. I'm not a technician who learnt your shitty software to do the most basic tasks.
I like 1-index because its what I learned first, and you like 0-index because that's what you learned first
We just need to compromise, arrays start at 0.5
Web development feels like it's stuck in the early 2000's. I've ranted a lot about it over the years but I just don't know how everyone is okay with it. I'm sure tons of people will disagree.
HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let's be honest, your webpage just consists of nested <div> tags.
CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it's just terrible. It's very clunkily integrated with HTML too in my opinion. Styling and markdown should be one easier to use language where 50% of it isn't deprecated.
Javascript has been memed to death so I won't even go there. Typescript is OK I suppose.
And now for my hottest take: ~10+ years ago I saw web building tools like Wix and I completely expected web development to head in the direction using a GUI to create, style, and script from one interface, even allowing you to create and see dynamic content instantly. I've seen competitors and waited for "the big one" that's actually free and open source and good enough to be used professionally. It never happened. Web dev has just gone backwards and stuck in its old ways, now it's a bloated mess that takes way more time than it deserves.
The Godot engine is actually a pretty good option for creating GUI apps and it's exactly what I envisioned web dev should've been this past decade. One language, intuitive interface, simple theming and easy rapid development... Shame it never happened.
One language
Godot has native support for 3 languages and community support currently built for like 6 other languages.
But the main language is GDScript, everything else is an alternative if you prefer not to use it.
Dynamically typed languages don’t scale. Large project bases become hard to maintain, read and refactor.
Basic type errors which should be found in compilation become runtime errors or unexpected behavior.
Most modern software is way too complex for what it actually does.
Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you're using a hammer on everything. There is no silver bullet in life and most undeniably not in programming.
Also, electron has a reason for existing. If it didn't have a use, it wouldn't have the number of users it has. You can't tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.