This is another thing where hobby and professional development diverge.
For professional development, freedom just means unmaintainable code. For projects that run for a longer time you want everything to be as standardized as possible. People 10 years from now will need to understand your code, even if they live in a different country, went to a different university and haven’t seen any code from your organization before they join the project.
Cool and clever tricks will likely cause more trouble in the future than they will ever be worth right now. You write code once, but you will keep reading and re-working it over and over again.
I have been using it since before I was a teenager and I still don’t know how many of its features work because I’ve never had a use for them. Things like templates and stuff.
This is exactly the issue here. When you stumble upon code that uses an obscure feature like that, it’s a “wtf moment” and it will likely result in something being used wrong and something causing a bug. We don’t want that.
That’s why close to every professional project uses a linter, which blocks you from using problematic patterns and illegible code. If you use C with a linter, it will force you to format your code in a certain way as well.
If you just DIY your own small projects and discard them before they become old, code style doesn’t matter. But if you ever looked at the code of one of your old projects and it took you a while to understand what you did there, then that’s the result of bad code style.
DarkAri@lemmy.blahaj.zone 2 days ago
I think it depends a lot on what you are doing. For game dev, there is really nothing else but C++. Also most bad code can be good code if someone is intelligent about it, and use good names and comments. Also if they know how to search through the code and trace things. For massive group projects I can kind of see your point. Being ina. Rush makes it very difficult to write good code, something that is laid out well, is interfacable and modular which makes it easier to understand. I personally try to write all my code to where it’s mostly an API to anyone else wanting to use it. Something where they don’t necessarily have to dig through tons of esoteric and confusing code, but I like to have everything wrapped in nice little function calls, that handle all the edge cases within and have a little description.
I understand rushing makes this hard but that’s more so a failure of the team leadership prioritizing the wrong things. If you are going to write code that’s going to be used for 20 years, it’s actually a much better use of your time to just write really clean and easy to understand and adapt code up front, and save yourself so much time in the future. The only time other people should really have to dig beyond the API layer of your code is when they need to debug or modify the functionality of your code. So to me it seems like you want to write the most abstract and stable and simple interfaces code when working on long term projects with multiple people, even if it takes 4x as long, and for little personal projects and stuff that will only be compiled once, you may just want to through 100k lines of code in a file and compile it and then forget about it.
Other things I do is wrap things and simplify things myself. I create my own libraries which I know that you as a professional programmer hate to hear, but I do believe in the power of simplicity and abstract compression if you really want readable code. Libraries have to be maintained if they are to be used in production, but inlining some of your own code into every project you do is very useful and doesn’t rely on external libraries and can greatly simplify the code you need to write. I wrapped many C std lib stuff in my own code for this reason. It cuts my code in half often times, makes the code very readable and descriptive, and I can just add it to all my projects as a header instead of link libraries and stuff. Idk. Maybe sometimes you just have to weigh the upfront development time and cost with later reliability and simplicity, which I’m sure you do, but your managers might be wise to consider that as well. Having bad code isn’t just bad for developers, it makes people using your product dislike the products. There are many reasons to just take the time to write better code and use better techniques at the cost of time, and to truly be successful you have to look beyond the next quarterly report and stock price and do everything in view of the long term. Efficiencies are often small by themselves and not worth it, but overtime efficiencies and good habits snowball into massive permanent buffs.