161–170 of 245 posts
Earlier quoted context omitted.
I don't know if you're joking or not about the ASP classic.
I'm joking. I would not start a new project in Classic ASP in 2003, much less 2018. I did like it back in the day though and it was still a better choice than .Net 1.0. .Net 1.1 was okay, by 2.0 it was pretty decent. 4.0 beyond is fantastic IMO. I'm a bit of an MS fan though. I like their tools.
Earlier quoted context omitted.
Personally I thrive in this kind of environment, it's a kind of comfortable chaos. MVC5 is positively modern compared to many of the products I've worked with which have included (within the last 5 years) VB6 winforms but mostly aspx webforms. Understand that previous developers might not know what a DOM is have likely written ad-hoc jquery snippets, included 3 different versions of jquery-ui until they happened acro…
> if someone is working on a new part of the product or is fixing a bug in legacy code be absolutely ruthless in what you'll let passed in code review. This may not do you any favours socially but a reputation for harsh code reviews isn't all bad. In my experience this is the most important thing. I particularly focus on the "what the heck does this code even do" aspect - the person who is modifying the code needs to…
Earlier quoted context omitted.
Don't stress about code quality. Quality code is it's own reward. Yes, clean code is more fun to write and work with. But, just think of it as a different kind of optimization problem. If the investment is not going to pay off in the future, then it's not worth doing in the first place. PS: This is not giving up, it's about getting even better by becoming ever more flexible.
this is very selfish, unless you're the only developer in your shop. whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU
The 3rd time you touch a function is often a great time to make it awesome. However, a lot of code never reaches production and maintainability is more of an issue for code that survives.
There needs to be a sense of ownership and pride. Even my side projects are written then rewritten over and over again until I’m personally satisfied with my approach and the quality of the code. If I use a hack to get something done on code no one but myself will ever see, I still leave a shame comment (//mqudsi: this is an ugly hack because I was too lazy to clean up access to this global variable. Fix me.) We aren…
I think the problem is are you saying this as an individual or are you saying this as someone in leadership with power.
Place a premium all you want. But if you're a grunt, that opinion is going straight to dev null.
> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?
Not old. The author is probably young. Or a js dev. Or both.
I've tried this approach in the past and and it has made me very bitter. Eventually I realized that the company I worked for enforced no accountability for bad code, so I would often open the solution later and found a pile of ugly hacks or other mess. Code reviews? Refactoring? "We don't have time and no one is going to pay for it". Eventually you come to a conclusion that if no one cares then why should you? If any…
It can be very frustrating, but ultimately it's a reflection on you. Whether you're a coder, or a librarian, or a janitor, take pride in your work. Do the best job you can. If everyone else's code looks like crap, that's on them. When new people come on, they'll see your work compared to the slackers, and start emulating you, not them. Like anything in life: Do the right thing, even when you're surrounded by villains…
I'm not saying code quality doesn't matter, of course it does. But there is a bigger picture and if you don't take the time to become a part of that you will not be very relevant.
Earlier quoted context omitted.
this is very selfish, unless you're the only developer in your shop. whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU
Not just your coworkers today, "future you" as well. I've known of or read the situation where someone opens some old code, thinks "Who wrote this hot garbage?", and then realizes it was them.
Did it work? Can you read and understand it? Then it has value.
Earlier quoted context omitted.
It can be very frustrating, but ultimately it's a reflection on you. Whether you're a coder, or a librarian, or a janitor, take pride in your work. Do the best job you can. If everyone else's code looks like crap, that's on them. When new people come on, they'll see your work compared to the slackers, and start emulating you, not them. Like anything in life: Do the right thing, even when you're surrounded by villains…
A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful. I'm not saying c…
Earlier quoted context omitted.
A linter and code conventions are a way to make code more consistent and easier to switch between. At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. If I open a file and everything "just feels wrong" but I can't change it because enforcing my personal preferences are just my personal preferences is just making things worse that really takes some valuable energy a…
At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. I suspect this is the big point of disagreement between lint-advocates and many of those who are dubious. I generally don’t see big wins from collectivising code, and on the who prefer to treat people I’m working with as individuals who can be interacted with 1:1 vs an amorphous “the team” writing “the codebase”.
If you’re the guy that thinks having a 300 line function in an 8000 line class is just an individual way of expressing yourself you’ll have to fight me.
If you think real tabs is better than 4 spaces I shrug and let you have it your way.
Earlier quoted context omitted.
We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier…
IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves". lint [cosmetic | medium | serious] - you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you mi…
Regarding the changeset, I think you could roll that pretty easily with something like `git diff --name-only | xargs eslint`.