When the reviewer doesn't understand my Javascript it's his fault
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
But aren't you supposed to (at least in C#):
- Write clean interfaces
- Write classes with methods which implement those interfaces
- Write application which uses those classes and their methods through the interface?
Isn't MoronicSense™ nagging you about unused things actually teaching you to do things the wrong way around?
Stuff implementing an interface - or indeed any method accessible by outside code (meaning public or protected) - won't get flagged as unused. Only private (and internal?) methods, that other code cannot call bar reflection, gets flagged.
-
@Gąska "Supposed to" is commonly used as a synonym for "intended to." Strictly, "suppose" means "assume" — "Moses supposes his toeses are roses, but Moses supposes erroneously." It is also is used to indicate agreement, possibly reluctant agreement, with a request — "Oh, alright, I suppose you can go, but be home by 10 o'clock."
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
@Tsaukpaetra aren't those synonymous? Serious question.
In context, "supposed to" implies not just intent but also along the lines of "commonly claimed to".
-
@kazitor well... they are.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Regardless, it is retarded. Why would I waste time writing a method if I don't intend to use it? Why flag it at all? Or if you really need to flag it, how about some delay instead of instantly begging for fucking attention like an instagram fucking attention whore?
I've actually found it useful. Not so much when writing the code as when rewriting/refactoring. It lets you know you have some cruft out there that can be killed too. (I'd be okay with a delay, although including that in something like Intellisense seems difficult.)
-
@levicki Hard pass. That sounds like an even worse version of vi's state change nonsense.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Why is it always "our way or the highway?" with Microsoft products?
They learned this from Apple.
-
@levicki
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Why not be able to pick a mode which lets you focus on different aspects of code you are working on?
Why would that be so bad in your opinion?It introduces unnecessary complexity and confusion for absolutely no reason.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Just out of curiosity - how many different languages do you use regularly?
Just out of curiosity -- how many times per day you need to deal with operator precedence in a way that is counter-intuitive and different from the language default?
The default of which language? Memorizing a set of rules for one language isn't that hard (wasteful and still hard, but not that hard in comparison). It's memorizing very similar but subtly different sets of rules for different languages and not mixing them up that's the problem.
Anyway, the answer is zero. I never have this problem. Because I always use parentheses around each subexpression. With just two key presses, I lift a bit of cognitive burden from myself and from everyone else who has to deal with my code afterwards.
So, how many languages?
Aren't programming languages supposed to make lives easier, not harder?
No, that's what money is for.
Then what are languages for? To make life miserable? Then let's drop this charade and go back to writing everything in assembly, shall we?
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
Stuff implementing an interface - or indeed any method accessible by outside code (meaning public or protected) - won't get flagged as unused. Only private (and internal?) methods, that other code cannot call bar reflection, gets flagged.
Regardless, it is retarded. Why would I waste time writing a method if I don't intend to use it?
Because it might've been needed once upon a time but not anymore. A leftover from refactoring, for example. All in all, looking up dead code is a useful feature - but yes, it shouldn't be so much in-your-face. Like, make a toggleable item in View menu like the one for showing whitespace, but have it disabled by default.
intended = meant = indicates purpose on the side of an agent that supposedly made it so.
supposed = indicates a certain expectation from the side of the observer.After your and everyone else's posts, I've come to conclusion that it was indeed correct to use "supposed" in that sentence.
-
@levicki The complexity of making the user pick between one of several overlapping options, for no reason. It's like if every time you entered the bathroom, the door wouldn't open until you specified if you were washing your hands, taking a shower, shitting or pissing.
-
@hungrier Add shaving, taking medicine, and brushing my teeth, and my answer is "all of the above," every morning.
-
@hungrier said in When the reviewer doesn't understand my Javascript it's his fault:
the door wouldn't open until you specified if you were washing your hands, taking a shower, shitting or pissing.
None of the above, I'm the plumber and I'm replacing a waterline for the homeowner.
Bathroom: Access Denied: E_NOT_ENOUGH_REPUTATION
Filed Under: StackOverflow'd that for you
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
What would you like to do?
It looks like you're trying to write some code there! Would you like help with that?
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Usually, people are supposed to accept majority decisions when working in a team. You seem to be objecting to that.
And, again, it depends on your definition of "majority" and "decision."
Who's the majority? Lines of code? Past developers? Non-IT staff? Every team across dozens of international branches?
Having never ever seen multiple options put to a vote, It's not so much a decision as following the path of least resistance. The manager comes down from on high with their no-input decree and "fine, whatever, just don't fire me" counts every bit as much as any argument against it. If there's even any debate allowed at all. Expecting new people to immediately conform without question robs them of any participation in the decision.
Again, you're not seeing the weaponization and concealment aspects. You've just shut down your most passionate people and cannot see the correlation between that and mediocre products that limp along forever struggling to reach minimum viability. TDWTF is in no danger of running out of new material thanks to such blind idolatry. Don't ever think different when working with the Buddy Bears.
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
you're just a horrible co-worker
No, a horrible co-worker would constantly make messes for you to clean up and then waste their time and yours crying about your bracket placement rather than learning how to fucking program.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
No, a horrible co-worker would constantly make messes for you to clean up and then waste their time and yours crying about your bracket placement rather than learning how to fucking program.
Stop whining about it and write your code in the same style as your colleagues (assuming they also want to use a consistent style). It'll save a lot of time, and if the only way you can think of to express yourself is through your use of basic syntax in minor ways, you're not thinking hard enough.
-
Where the fuck do you work so I can avoid it like the plague. Because I have never experienced anything even remotely like that in the last 20 years of dev. work. Especially over something so trivial as a style sheet.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Everyone is beating their chest how AI will change things but it won't
It already has. Just not in the ways that retarded sci-fi fans with zero background in science have fantasized about. Just like every other invention of the last 150 years.
And IntelliSense doesn't have much to do with AI anyway.
- The options are not overlapping -- you don't need same code analysis features for writing code, debugging code, refactoring code, etc.
99% of the features I need for each of these things is indeed the same. It's just the last 1% that differs.
You know what has a lot of different modes for different tasks? Vim (and Emacs). You know what developers almost universally hate for having a lot of different modes you need to enter before doing something? Vim (and Emacs).
- You don't have to change this every time, think of it as a Photoshop workspaces but for Visual Studio. You pick the one you use most commonly, and change only when you need different rules.
Most of the time, I'm doing development and refactoring almost simultaneously. Having to enter separate mode for refactoring would introduce additional friction, and thus make people less willing to do refactoring (or they'd get accustomed to doing refactoring without ever using any refactoring-specific features VS offers).
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
"Continue without code" is by far my favorite option for a program whose sole purpose is writing code.
Ever debugged 3rd party EXEs?
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
There could be "[ ] All of the above" setting available too, which would work like it does now and pester you to no end about everything all the time if that's how you like it, you fucking masochist.
Why are you so bothered by the presence of IDE warnings and suggestions? And if it bothers you that much, I'm sure there's a configuration option that you can tweak to turn off the ones you don't like.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
From what I see they claim it does tasks a competent developer can do on their own.
Sure. But why use the expensive developer's time on it if you can use cheap CPU time instead?
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
I am bothered because they are fighting for my attention and steal my focus which should be on the code I am working on, not on some petty trivial issues their retarded Roslyn analyzer can catch which I am already aware of.
If you're not careful you might misremember an operator precedence
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
From what I see they claim it does tasks a competent developer can do on their own.
Sure. But why use the expensive developer's time on it if you can use cheap CPU time instead?
So an AI which is not capable of determining when a method was written and spams you with useless lightbulbs and squiggles
It's only not capable of it because it wasn't programmed to be capable of it.
can suddenly tell you with confidence what areas you should focus on in the code review and help you fix difficult-to-catch code issues?
Yes, because it's been programmed to do that. "Areas to focus on" is rather vague, so discussing whether it does so well or not won't get us anywhere because you'll just refuse to acknowledge what I would say on the matter - but difficult to catch issues is pretty specific, and IntelliSense absolutely does provide tools to detect at least some of them, and because of the nature of computers, it does so very consistently (if there is an issue it can detect, it will detect it, and will detect all instances of it in arbitrarily large codebase - with zero effort from the user).
Give me a break please. Not even you could believe that
Believing marketing is one thing (and I'm not falling for it, no; this is the worst description of what IntelliSense actually does I've ever seen). But you outright refuse that a computer program can ever be any help in detecting issues with code. Static analysis is a thing. It works. It brings real benefits. And IntelliSense is capable of it. It's just overzealous at times and its UX leaves much to be desired.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Changing code according to Visual Studio code analysis suggestions is something that I would like to be able to choose when I am going to pay attention to and with current options I can't.
Why not? If you don't want to implement whatever Visual Studio is suggesting, you can
Not do it
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Most of the time, I'm doing development and refactoring almost simultaneously.
Almost missed this "gem".
AFAIK, best practice is not to mix unrelated code changes into a single commit.
Who fucking cares about single commits? People only ever use branch heads and named tags anyway. Except when looking for who wrote a particular line and when, but in this case, splitting changes in multiple commits only means you have to traverse more commits.
And "unrelated" is quite ill-defined. Is refactoring the very same 300-line class that I'm putting two brand new methods in related or not? I'd say yes, it's very related, it's the same functionality goddammit. But you'd (I assume based on your post) say that no, because development and refactoring are separate activities. And we'd both be just as correct!
If you really need to refactor some part of existing code in order to develop new functionality, then refactor, test and commit.
Once that is done you can start developing you new feature which goes in a separate commit.What if the refactoring doesn't make sense without new feature? What if the new feature doesn't make sense without refactoring? I run into this issue all the time. Mind you, the refactorings I'm talking about are very small in scope. The large ones are separate tasks with separate feature branches that are reviewed and merged into main branch separately.
Also, not all refactoring is the same.
But they all use the same IDE features, at least in my experience. I can't think of a single feature that makes sense in large scale that doesn't make sense in small scale too.
Changing code according to Visual Studio code analysis suggestions is something that I would like to be able to choose when I am going to pay attention to and with current options I can't.
You can do that already. The only problem is that the relevant checkbox is three levels deep in options window. But I'm sure there's an extension somewhere that puts it right there in toolbar.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@hungrier said in When the reviewer doesn't understand my Javascript it's his fault:
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
I am bothered because they are fighting for my attention and steal my focus which should be on the code I am working on, not on some petty trivial issues their retarded Roslyn analyzer can catch which I am already aware of.
If you're not careful you might misremember an operator precedence
For trivial operations I have it memorized, for more complex formulas I specify explicit order using
()
Pussy.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@hungrier said in When the reviewer doesn't understand my Javascript it's his fault:
Why not? If you don't want to implement whatever Visual Studio is suggesting, you can
So if someone is following you around 8 hours per day suggesting you to take your panties off so they can fuck you up the butt every time you change state (sit/get up/lay down), your solution is to "not do it"? The nagging which you cannot disable wouldn't bother you at all? Brillant.
But it can be disabled.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Suppression files do not count.
Custom rulesets do not count.Out of curiosity, why not?
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
splitting changes in multiple commits only means you have to traverse more commits.
But it also means that you can cherry-pick commits in case your client decides they don't want one of the changes anymore or if you introduced a bug its easier to locate it (and excise it) in a dozen of small separate commits than in a gigantic single commit.
I've never had to cherry pick changes in smaller quantities than one complete feature/bugfix from start to finish. And each feature/bugfix gets its own branch.
What if the refactoring doesn't make sense without new feature? What if the new feature doesn't make sense without refactoring?
- Refactor and guard against new feature with flag
- Add feature and remove guarding flag
That way you still get two independent commits and don't risk breaking things with a single big change.
Step 1 still requires me to write half the code for the new feature (there's a reason why the refactor requires the feature) - so you still end up with a single big change, but now accompanied with a much smaller second change that fills in the missing bits in implementation. Alternatively, you don't implement the required parts of the feature needed to support the old code after refactoring, and now everything is broken between the two commits (there's a reason why the refactor requires the feature)
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Pussy.
Ass.
Of course I'm going to be an ass when in one thread you chastise me for putting superfluous parentheses in my code because I don't want to memorize all precedence rules, and in another you admit to doing the same thing.
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
But it can be disabled.
Show me how, but:
- Suppression files do not count.
- Custom rulesets do not count.
Oh, so your complaint is that the default settings suck, not that it cannot be done? Then you should've said the default settings suck, not that it cannot be done.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
So if someone is following you around 8 hours per day suggesting you to take your panties off so they can fuck you up the butt every time you change state (sit/get up/lay down), your solution is to "not do it"? The nagging which you cannot disable wouldn't bother you at all? Brillant.
Do you get this worked up about other IDE features? "This unused variable warning is like someone holding a gun to your head shouting at you to give them all your money!"
-
@kazitor said in When the reviewer doesn't understand my Javascript it's his fault:
@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:
Well no, I made the timeout really long, see here? 1.5 seconds!
Problem solved
I'm ashamed to have to admit that just today I fixed a bug by changing the duration of a sleep from 300ms to 2000ms.
Of course the sleep was in a CUnit-hosted unit test(1)(2) rather than the actual production code, but even so...
(1) The codebase is a festering mess(3) designed by two younger developers who have since left the company for other reasons, loosely supervised by a semi-senior who has also left the company. In concept, at least, it's fairly simple, except that they got hold of C++11 and went hog-wild with it. The code is liberally strewn with async-callback lambdas, and in fact, some of them have other async-callback lambdas inside.
(2) For unknown and unjustifiable reasons, the code in question is C++, but tested using CUnit rather than CPPUnit. The CUnit "FATAL" macros, of course, use
longjmp
to bail back to the framework, which is prime UB material in C++, and doubly so because my charming colleagues decided to invoke it in worker threads spawned by the main CUnit thread. (Um. The correspondingsetjmp
was called in that main thread, duh.)(3) In concept, at least, the feature is pretty simple, but they had a major brain-fart, and the code resembles the worst excesses of Brooks's "Second System Effect" even though it's a "First System". The design goal was immensely ambitious, much more so than the product can ever use(4), and the feature is heavily burdened with non-deterministic behaviour because it's a messaging layer based on a messaging layer(5) that includes such gems as an object called "socket" whose behaviour is almost entirely unlike BSD sockets.
(4) I've made liberal use of the turbine-powered code-deletion axe(7) I keep in my other back pocket(6), and it's still overly ambitious. It will be put into the next release of the main software set (which enters feature-freeze at the end of next week), and for the release after that, the code-deletion axe will have been busy again, and the CUnit tests I kludged into determinism today will no longer exist and neither will the module that they test.(8)
(5) I shall not name it, but a common way of writing its name might be paraphrased as "null emqueue". For its target use-case, it's not bad, but my ex-colleagues decided to use it for something almost entirely unreleated to that use-case. But yes, you read that right. A messaging layer based on a messaging layer. I am not joking.
(6) The one that doesn't have the GAU-8 in it, duh.
(7) So much so that there is now a standing joke in the team: "What did Steve do this week?" "He deleted some code."
(8) Yes, I've deleted so much code that one part of the system no longer serves any worthwhile purpose, but it does just enough and the feature-freeze date is just soon enough that it's too late to finish the job.
Sorry. This bundle of code has been causing me ... stress ... and I needed to vent.
-
@Steve_The_Cynic said in When the reviewer doesn't understand my Javascript it's his fault:
I've deleted so much code that one part of the system no longer serves any worthwhile purpose, but it does just enough and the feature-freeze date is just soon enough that it's too late to finish the job.
-
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
@Steve_The_Cynic said in When the reviewer doesn't understand my Javascript it's his fault:
I've deleted so much code that one part of the system no longer serves any worthwhile purpose, but it does just enough and the feature-freeze date is just soon enough that it's too late to finish the job.
More "Defactor" than "Refactor", but yes, pretty much that.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
splitting changes in multiple commits only means you have to traverse more commits.
But it also means that you can cherry-pick commits in case your client decides they don't want one of the changes anymore or if you introduced a bug its easier to locate it (and excise it) in a dozen of small separate commits than in a gigantic single commit.
Is refactoring the very same 300-line class that I'm putting two brand new methods in related or not?
If two new methods can work without refactoring then it's not related.
What if the refactoring doesn't make sense without new feature? What if the new feature doesn't make sense without refactoring?
- Refactor and guard against new feature with flag
- Add feature and remove guarding flag
That way you still get two independent commits and don't risk breaking things with a single big change.
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
The only problem is that the relevant checkbox is three levels deep in options window.
Screenshot or it didn't happen.
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Pussy.
Ass.
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
But it can be disabled.
Show me how, but:
- Suppression files do not count.
- Custom rulesets do not count.
How do you get through life if this trivial feature of IDEs bothers you this much? Yes, these IDE suggestions (from VS and IntelliJ anyway) can be annoying sometimes. So what? I'm trying to decide if this is literally the worst thing about your job in which case you have an amazing job. Or, if this trivial thing is just what breaks the camel's back because of other crap going on at work.
For that particular code suggestion, I've probably had it be 10x more useful than annoying in a fairly large and creaky codebase that had a lot of dead code because of previous laziness.
As I've gotten older, I've come to embrace The Church of IDE Defaults regarding code suggestions, tabs vs spaces, space around keywords, tab width, etc. I just don't care enough anymore to mess with the settings. The most I'll do is import a settings file (for IntelliJ anyway, not sure if VS has that) to use a company's settings.
-
@dkf No.
Must be like nails on a chalkboard for those that never hear it. No. No! NO!
And a special to all of the style Nazis out there. Mein Code liegt nicht in Ihrer Hand.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
determine from past commit history
yeah right. It has only recently begun doing things for the not-even-commited stuff, and now you want it to analyze history?
Methinks you dream too far in the future...
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
there is no such option
Notepad.
-
@hungrier said in When the reviewer doesn't understand my Javascript it's his fault:
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Changing code according to Visual Studio code analysis suggestions is something that I would like to be able to choose when I am going to pay attention to and with current options I can't.
Why not? If you don't want to implement whatever Visual Studio is suggesting, you can
Not do itNo no no! The 💡 will not be ignored! You must attend it mid-keystroke! Or else!
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
trying to concentrate
Ah, so you want Notepad with Zen mode then.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
@dkf No.
Must be like nails on a chalkboard for those that never hear it. No. No! NO!
And a special to all of the style Nazis out there. Mein Code liegt nicht in Ihrer Hand.
I'm late to the thread here, but I think your biggest problems are
- Godawful coworkers
- Godawful company
- Fighting against 1) and 2) by declaring that You Will Not Bend.
You are not a rockstar. (Honestly, nobody is.) The company's codebase does not revolve around you. You (and I) are simply not important enough that our code-style predilections justify putting everyone else out of joint.
Code styles are all slightly dumb. The better ones have fewer rules than average, and have a little bit of "that part there isn't important enough to have a rule about". But they beat the pants off of having every special snowflake cowboy applying their own "best" style to whatever code they happen to be editing at the moment. Either run the linter right before the code review, or run it as you type (I use on-save), but get the stupid style arguments out of the way automatically. Stick in the disable-linter commands whenever you need an exception – they're pretty rare.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
You know what developers almost universally hate for having a lot of different modes you need to enter before doing something? Vim
Heathen!!
(and Emacs).
Yes! (although being modal is not the reason for hating it).
Filed under: Editor wars, round 3635845
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Of course I'm going to be an ass when in one thread you chastise me for putting superfluous parentheses in my code because I don't want to memorize all precedence rules, and in another you admit to doing the same thing.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Vim
All hail the one true editor!
-
@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Vim
All hail the one true editor!
Er, the One True Editor is called EDLIN.
EDIT: or maybe the EDT part of EDTASM.
-
@PotatoEngineer
Don't bother. I've already tried to tell him that and the reply was an incoherent rant about the involuntary nature of job duties. It was implied that asking employees to adhere to rules is somehow immoral. I'm not sure whether the rant contained the phrase "Am I being detained?", but it might as well have.
-
Unfortunately, all criticism needs to be exactly 51 characters wide, with hangovers broken on consonants only, and every 5th word must be colored incrementally following Crayola's 64-color box layout (making the 40th word periwinkle), otherwise you're not thinking hard enough and a bad communicator.
But, fear not, spellchecking and grammar opshunal hello goodbye.
-
Speaking of refactoring:
This fucking thing.
The underlying field is publicly available. And the things that use it actually use the field pretty much immediately most of the time.
Who the fuck did this?!?!
-
@Tsaukpaetra: aren't you the only developer on this project?
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Unfortunately, all criticism needs to be exactly 51 characters wide, with hangovers broken on consonants only,
Well, those rules would certainly cause heavy drinking.
-
@Grunnen said in When the reviewer doesn't understand my Javascript it's his fault:
What do you think about this?