Spyke

Syndicated from the fediverse. Read and engage on the original instance.

View original on programming.dev

31 replies

SharePoint, Teams, OneDrive, Entra ID and M/O365 aren't "stupid". Your problems and complaints are the result of user error (although, to your credit, Microsoft in no way makes their intended use obvious or intuitive).

Don't take that as an endorsement of them or Microsoft. On a consumer level, you should actively avoid them all. I'm referring to people who have to use them at work and complain about intended behavior being "stupid" or "pointless". If you learn enough about how it works, you realize it either makes sense or is simply a limit of "the cloud".

-1

Idk man I've never heard someone talking shit about slack. I think teams might actually be bad software.

4
ani.social

useState hook is an actual plague on the entire React ecosystem

Personally, I find useEffect to be the real evil.

3

The default clang-format configuration is absolutely horrendous, but for our company we had an in house clang-format configuration that actually made the code look quite good. The problem is you still have to control code spacing/some alignments yourself.

3
feddit.online

Using LLMs are not the same as using intellisense or compilers and there are a myriad number of reasons not to use it that could fill an entire book and I will look down on any company or freelance developer that uses it.

Yes I'll fight Linus over this and yes I'll be right.

7
ani.social

No idea how much of a hot take it is but i find virtual to be a plague upon a codebase.

There are a few very rare use cases for it, but imo most cases where developers use virtual they can use templates instead to achieve the same result.

2

Why does it make zero sense in C++?

edit: simplified example of what i mean

struct A {
    virtual void DoSomething() = 0;
};

struct B : A {
    void DoSomething() override { 
        std::println("B"); 
    }
};

struct C : A {
    void DoSomething() override { 
        std::println("C"); 
    }
};

void InvokeDoSomething(A* a) {
    a->DoSomething();
}

vs

struct B {
    void DoSomething() { 
        std::println("B"); 
    }
};

struct C {
    void DoSomething() { 
        std::println("C"); 
    }
};

template <typename T>
void InvokeDoSomething(T* t) {
    t->DoSomething();
}
1
midwest.social

Linters are terrible.

Style/formatting linters, anyway, particularly when it comes to whitespace. The goal of formatting code with whitespace is to optimize for human readability. A linter based on a set of rules is not human and thus cannot judge human readability. There is really no formatting rule you can write that will not someday have exceptions on a large-enough codebase.

Contributors should be responsible for submitting readable code, and ensuring that is what reviews are for.

3

I'll go a step further: formatting for human-readability is the job of the reader, not the writer. Hardcoded line breaks, spacing, etc. are never going to be a good solution because the idea is wrong from the start. This is a display issue, not a logic issue. It needs to be solved at the display end.

Use a syntax-aware editor that formats code the way you like it. Save it any goddamn way that is syntactically valid. Anyone else who opens it will see it any way the like in their own syntax-aware editor.

"But my editor doesn't do logical formatting!" Yes, because the entire world has been insane for several decades, and shitty editors are normalized. If the world had realized this 30 years ago, there wouldn't be a code editor in existence today that didn't do this properly. Demand better and better will be normalized.

1
PattyMcBreply
lemmy.world

Ooh... good one, but any good IDE and/or source control will convert tabs to spaces anyway.

5

Any good IDE and source control should convert spaces to tabs. QED

4
lemmy.zip

Care to elaborate on this? Not saying you're wrong necessarily, that's just a pretty bold claim and I'm curious why.

9

React works by maintaining a virtual representation of the DOM. When you dispatch state changes into the virtual DOM react can determine which components depend on the change and which side useEffects run.

My gripe is that YouTube tutorials teach that the useState is the equivalent of a variable. This encourages average developers to problem solve solutions that end up using React's Virtual DOM for business logic. The YouTube tutorials have react devs planting 100s of useStates - some of which don't directly induce a visible-on-screen rerender - and then ⅒ as many useEffects to bind these states together. This means that for the Virtual DOM to come to the conclusion as to what html elements need to be changed and how it has already mutated 20-50-100s of times and the CTO tells me the react app is slow and they're mad.

If 2 states have the opportunity to mutate each other back and forth then the truth is that you have 2 perspectives of the same state. And React gives you solutions for that - proper solutions - the useReducer hook is for defining these complex state mutations and the Context API for communicating that state to any component.

And this has me quintuple pissed off because these same tutorial grade react devs install REDUX as compulsively as a pack-a-day smoker (that's #3). They use Redux to file variables in JavaScript memory (that's #4) like it's a global variable and rarely if ever use it for the complex state mutations they need instead I've seen react devs write components pull state out of redux into a component just so it can mount useEffect and process the state and dispatch the result back into redux. Let's not even bring up how the react-redux binding library literally uses the React Context API (that's #5).

4

I don't like working with them any more than you do, but they're necessary to enforce read/write-level security. Without them, there'd be no differentiation between reading a variable and writing variable from an external class, which kinda defeats the point.

From a development standpoint, they're an extra hurdle to clear. From a security standpoint, they're a necessary evil.

5

That's why people invented properties / auto generated getter/setter - in at least 95% of cases they are just busywork.

12

You reached the end