>he actually delivers working products
good one pajeet
That's TypeScript. Also, it doesn't look too awful. getSize is kind of cringe, could just math.max it or handle completely differently. But it's all right.
and yet the types are immediately broken by `Object.keys`
> posts code > simple, clean > getsize is a bit lame, but is only a few lines so nobody gives a shit
seek help for your mental moronation, anon.
thanks sanjay, how's the blog coming along?
3 weeks ago
Anonymous
>how's the blog coming along?
you mean your blog? everyone here seems to think that you're moronic. think there might be something to it?
3 weeks ago
Anonymous
Funny, the same people glanced over the unnecessarily complex o(n log n) function at the bottom. >but using indexOf() makes it so much easier to understand!
Don't worry pajeet, it's okay. Keep writing shit
3 weeks ago
Anonymous
>Don't worry pajeet, it's okay. Keep writing shit
projecting much? i'm not a programmer, just making observations based on the content of this thread. but you do you.
3 weeks ago
Anonymous
I don't think OP's retaded, he's just in the wrong career.
That's TypeScript. Also, it doesn't look too awful. getSize is kind of cringe, could just math.max it or handle completely differently. But it's all right.
i would just use this in LayoutSettings:
columnSize: {
1: 'xs', // Maps to the 'xs' breakpoint
2: 'sm',
3: 'sm',
4: 'sm',
5: 'md',
6: 'md',
default: 'lg', // Default mapping for any count > 6
}
Why not use an array when the keys are this sequential? Should be less costly than a hash map lookup and virtually the same textual complexity so why not?
I'm not a JS man, so forgive me if I miss something obvious.
3 weeks ago
Anonymous
I like your refactor. (:
const getSize = (columnCount: number): number => {
const fact = (n: number): number => (n > 1) ? n * fact(n - 1) : 1;
let size = 3;
for (let i = 1; i < 4; i++) {
if (columnCount < 1 + i * 2) {
break;
}
size += fact(i);
}
return size;
};
great for good looks
why use recursion and an extra function for such a simple problem? Feels like you made it harder to read.
Also, that would create an instance of the fact function every time you called getSize.
Why not use an array when the keys are this sequential? Should be less costly than a hash map lookup and virtually the same textual complexity so why not?
I'm not a JS man, so forgive me if I miss something obvious.
usually hash maps are stupidly fast in JS. it probably wouldn't have a meaningful difference, even if that code was run in a game loop.
if you're optimizing for performance in JS, watching out for allocations is a good idea. Those will always be expensive.
3 weeks ago
Anonymous
based: clean, simple, and doesn't need much more time to change them later
3 weeks ago
Anonymous
>repeating 'sm' 3 times
OMG!!!!!! DRY!!!!! WHAT ABOUT DRRRRY!!!!!
[...]
i would just use this in LayoutSettings:
columnSize: {
1: 'xs', // Maps to the 'xs' breakpoint
2: 'sm',
3: 'sm',
4: 'sm',
5: 'md',
6: 'md',
default: 'lg', // Default mapping for any count > 6
}
Is there no "list out of range" error in typescript ?
3 weeks ago
Anonymous
>Okay but isn't your intent less obvious ?
Not the poster. The code's alright because i is so small. I think for frontend work, it might be the case that code should be more readable than performant. But those if statements are cancer.
I like your refactor. (:
[...]
why use recursion and an extra function for such a simple problem? Feels like you made it harder to read.
Also, that would create an instance of the fact function every time you called getSize.
[...]
usually hash maps are stupidly fast in JS. it probably wouldn't have a meaningful difference, even if that code was run in a game loop.
if you're optimizing for performance in JS, watching out for allocations is a good idea. Those will always be expensive.
Okay but isn't your intent less obvious ?
[...]
Is there no "list out of range" error in typescript ?
>fricking recurssion
lol!
idm this. fact isn't so bad since i is at most 3
const getSize = (columnCount: number): number => {
let fact = 1;
let size = 3;
for (let i = 1; i < 4; i++) {
if (columnCount < 1 + i * 2) {
break;
}
fact *= i;
size += fact;
}
return size;
};
>> simple, clean
You mean entangled mess of mutability and pointless variables.
Computing a flex layout is a pure, deterministic problem.
If you need to track and modify the state of several arrays and variables you're 100% positively moronic.
>magic numbers everywhere >"i can read it, so it's good"
okay, write a function to determine if the input is a multiple of 2. Why not write a few thousands lines of if statements to check if number == 2, if number == 4, if number == 6...etc. That's readable, right? So it must be good. Fricking moron, what an idiotic argument
> posts code > simple, clean > getsize is a bit lame, but is only a few lines so nobody gives a shit
seek help for your mental moronation, anon.
> getsize is a bit lame, but is only a few lines so nobody gives a shit
A few lines serving as tip of the iceberg, pajeet.
Why this? slice(0)
Isn't that just the original array?
Yes, but at least it makes it clean and simple to understand, right?
yeah it all makes sense now why you're not a senior and just nothing more than a shit kicker, possibly on a designated shitting street somewhere in india. learn to cope with being dabbed on.
kek good post. left is objectively better but corpos will always push for right and it's moronic.
>corpos will always push for right and it's moronic.
I work corpo and not a single dev on my team would push for the right version.
You'd know that if you actually worked.
0) If the strings to replace are known AOT just replaceAll(symbol, translation)
1) The capture group matched and contains begin, end indices. There is no point constructing replace that will iterate the string again and search for the pattern that you already found again.
2) The symbolMatcher.find() starts the search from 0th index every time instead of starting where the end of last match was found. This is pajeet tier.
2a) You can either accumulate the [start, end] match indices which will produce a list of slicing/strBuilding operations.
2b) Update the string at the match time, but beware that the end index must be updated because the translated string may be less, greater or equal in length to it's key symbol. But it can be done by just using min($symbol.length, translatedSymbol.length) as the new startIndex for find (it will backtrack the index if the translated string was less) which is the simplest thing that can be done without doing several ifs, and losing at most few characters at worst if the translated string was greater (it's a safe succint option that is still better than starting from 0th every time), but if it matters ifs can be used and moving the end index to the translated string length if it's greater.
3) The regex is completely unnecessary, because indexOf with the same loop will do the same thing.
4) The alreadyReplaced array is not needed unless there is some other purpose than tracking if something was replaced in the string.
4a) If the count of replacements is needed we already know it because we entered the while body, so the counter could be incremented after replacement.
4b) If the positions of replacements is needed for logging or whatever we already know it because the capture group already had begin, end indices.
4c) We can also have the information about what [start, end] indices pair map to what new [start, end] indices pair if you need that sort of information.
Conclusion: it's neither the simplest solution nor the best
meh, put the if-else block in a switch and give the random ass magic numbers a symbolic name (or use the god damn layoutSettings he created for exactly that purpose). And rename x to something more understandable. I don't want to have to think about that shit when I'm reviewing PRs. Then make sure it passes unit and integration tests, and then make sure the client is happy. Boom, done.
That looks fine to me, from a readability point of view. IMO, that's the most important one in most cases.
There are ways to optimize it, I believe, but I wouldn't make it less readable for that, unless we identified that this code is a performance bottleneck. If it's not a hot path, then it's likely to be meaningless.
What's wrong with it? It's pretty readable and indented, function and variable names are OK, only those ifs could have been written in a better way, but hey, if it's working and you can understand, good enough for me.
The guy is making money and you're here wasting time at IQfy trying to shame him without any proper reason, does it make you feel better with yourself? Go figure.
breakpoint shouldn't be string. should use guards in the getSize method, to make it smaller, and better microperformance. his current method does useless if checks. for every case it will do 4 if checks.
Code quality isn't the primary feature of a lead dev. A lead dev is someone who can develop project requirements and execute on those requirements in a timely fashion and deliver an acceptable product, lead devs also are capable of mentoring junior devs and able to communicate to management.
My main gripes with that code is the lack of comments, lack of new lines, and doing multiple tasks on single lines. This type of code will be prone to bugs and is a pain in the ass to debug weeks or months down the road.
I have no idea what I'm reading.
>LGTM!
looks fine to me. maybe he's making 8k a month because he actually delivers working products?
>he actually delivers working products
good one pajeet
and yet the types are immediately broken by `Object.keys`
notice how nobody in this thread actually gives a fricking shit? there's a reason for that. hope your mental moronation heals up soon, anon.
thanks sanjay, how's the blog coming along?
>how's the blog coming along?
you mean your blog? everyone here seems to think that you're moronic. think there might be something to it?
Funny, the same people glanced over the unnecessarily complex o(n log n) function at the bottom.
>but using indexOf() makes it so much easier to understand!
Don't worry pajeet, it's okay. Keep writing shit
>Don't worry pajeet, it's okay. Keep writing shit
projecting much? i'm not a programmer, just making observations based on the content of this thread. but you do you.
I don't think OP's retaded, he's just in the wrong career.
I think he's moronic AND also in the wrong career
Pajeet is actually right
>and yet the types are immediately broken by `Object.keys`
no they're not? it's just a map
That's TypeScript. Also, it doesn't look too awful. getSize is kind of cringe, could just math.max it or handle completely differently. But it's all right.
how would you do getSize better ? I don't know shit about Typescript.
fortunately the senior dev has since been replaced (by guess who)
const getSize = (columnCount: number): number => {
const fact = (n: number): number => (n > 1) ? n * fact(n - 1) : 1;
let size = 3;
for (let i = 1; i < 4; i++) {
if (columnCount < 1 + i * 2) {
break;
}
size += fact(i);
}
return size;
};
great for good looks
>fricking recurssion
lol!
idm this. fact isn't so bad since i is at most 3
i would just use this in LayoutSettings:
columnSize: {
1: 'xs', // Maps to the 'xs' breakpoint
2: 'sm',
3: 'sm',
4: 'sm',
5: 'md',
6: 'md',
default: 'lg', // Default mapping for any count > 6
}
makes getSize a lot simpler.
export const getSize = (columnsCount: number, breakPoint: string): number => {
const sizeKey = LayoutSettings.columnSize[columnsCount] || LayoutSettings.columnSize.default;
return LayoutSettings.breakpoints[sizeKey][breakPoint];
};
Why not use an array when the keys are this sequential? Should be less costly than a hash map lookup and virtually the same textual complexity so why not?
I'm not a JS man, so forgive me if I miss something obvious.
I like your refactor. (:
why use recursion and an extra function for such a simple problem? Feels like you made it harder to read.
Also, that would create an instance of the fact function every time you called getSize.
usually hash maps are stupidly fast in JS. it probably wouldn't have a meaningful difference, even if that code was run in a game loop.
if you're optimizing for performance in JS, watching out for allocations is a good idea. Those will always be expensive.
based: clean, simple, and doesn't need much more time to change them later
>repeating 'sm' 3 times
OMG!!!!!! DRY!!!!! WHAT ABOUT DRRRRY!!!!!
Okay but isn't your intent less obvious ?
Is there no "list out of range" error in typescript ?
>Okay but isn't your intent less obvious ?
Not the poster. The code's alright because i is so small. I think for frontend work, it might be the case that code should be more readable than performant. But those if statements are cancer.
lol, fricking butthole
const getSize = (columnCount: number): number => {
let fact = 1;
let size = 3;
for (let i = 1; i < 4; i++) {
if (columnCount < 1 + i * 2) {
break;
}
fact *= i;
size += fact;
}
return size;
};
hello sirs, is this better?
>it's all right
"alright" doesn't cut it for a 30+ year old lead.
Management doesn't give a shit. They just want work to get done. Better to get it done than spend hours making it perfect.
it looks like clean code
yeah, getSize really is the cherry on top
> posts code
> simple, clean
> getsize is a bit lame, but is only a few lines so nobody gives a shit
seek help for your mental moronation, anon.
>> simple, clean
You mean entangled mess of mutability and pointless variables.
Computing a flex layout is a pure, deterministic problem.
If you need to track and modify the state of several arrays and variables you're 100% positively moronic.
I can read this code and understand what it does.
This man deserves a raise.
>magic numbers everywhere
>"i can read it, so it's good"
okay, write a function to determine if the input is a multiple of 2. Why not write a few thousands lines of if statements to check if number == 2, if number == 4, if number == 6...etc. That's readable, right? So it must be good. Fricking moron, what an idiotic argument
> getsize is a bit lame, but is only a few lines so nobody gives a shit
A few lines serving as tip of the iceberg, pajeet.
Yes, but at least it makes it clean and simple to understand, right?
Getting irrationally angry at a senior dev's (perfectly fine) code is the reason why you're not a senior dev.
yeah it all makes sense now why you're not a senior and just nothing more than a shit kicker, possibly on a designated shitting street somewhere in india. learn to cope with being dabbed on.
nice reasoning. i don't recall saying i wasn't a senior? calm down pajeet, you're hallucinating.
this guy writes better code than you, that's why he makes twice what you make
seethe moron
Why this? slice(0)
Isn't that just the original array?
probably clones it. array sort methods tend to mutate whatever you run them over
NOOOOOOOOOOOOOOOOOOOO YOU MUST HECKIN REFACTOR IT!!!!!!!! UNCLE BOB WOULD NOT BE PROUD!!!!!!!!!!!!!!!!!
>sort((a, b) => sortingArr.index0f(a.id) - sortingArr. index0f(b.id));
kek good post. left is objectively better but corpos will always push for right and it's moronic.
>corpos will always push for right and it's moronic.
I work corpo and not a single dev on my team would push for the right version.
You'd know that if you actually worked.
You're wrong. They prefer the right because it can be fully unit tested and they all insist on that time wasting bullshit these days.
0) If the strings to replace are known AOT just replaceAll(symbol, translation)
1) The capture group matched and contains begin, end indices. There is no point constructing replace that will iterate the string again and search for the pattern that you already found again.
2) The symbolMatcher.find() starts the search from 0th index every time instead of starting where the end of last match was found. This is pajeet tier.
2a) You can either accumulate the [start, end] match indices which will produce a list of slicing/strBuilding operations.
2b) Update the string at the match time, but beware that the end index must be updated because the translated string may be less, greater or equal in length to it's key symbol. But it can be done by just using min($symbol.length, translatedSymbol.length) as the new startIndex for find (it will backtrack the index if the translated string was less) which is the simplest thing that can be done without doing several ifs, and losing at most few characters at worst if the translated string was greater (it's a safe succint option that is still better than starting from 0th every time), but if it matters ifs can be used and moving the end index to the translated string length if it's greater.
3) The regex is completely unnecessary, because indexOf with the same loop will do the same thing.
4) The alreadyReplaced array is not needed unless there is some other purpose than tracking if something was replaced in the string.
4a) If the count of replacements is needed we already know it because we entered the while body, so the counter could be incremented after replacement.
4b) If the positions of replacements is needed for logging or whatever we already know it because the capture group already had begin, end indices.
4c) We can also have the information about what [start, end] indices pair map to what new [start, end] indices pair if you need that sort of information.
Conclusion: it's neither the simplest solution nor the best
this isnt even that bad
stop snitching on your coworkers behind their backs for petty bullshit you fricking snake
>typescript
go frick yourself
Kek, meanwhile I'm unemployed. God I hate this world.
what's the problem exactly?
meh, put the if-else block in a switch and give the random ass magic numbers a symbolic name (or use the god damn layoutSettings he created for exactly that purpose). And rename x to something more understandable. I don't want to have to think about that shit when I'm reviewing PRs. Then make sure it passes unit and integration tests, and then make sure the client is happy. Boom, done.
That looks fine to me, from a readability point of view. IMO, that's the most important one in most cases.
There are ways to optimize it, I believe, but I wouldn't make it less readable for that, unless we identified that this code is a performance bottleneck. If it's not a hot path, then it's likely to be meaningless.
Let's see your refactor.
What's wrong with it? It's pretty readable and indented, function and variable names are OK, only those ifs could have been written in a better way, but hey, if it's working and you can understand, good enough for me.
The guy is making money and you're here wasting time at IQfy trying to shame him without any proper reason, does it make you feel better with yourself? Go figure.
Have you ever considered that he's a lead dev because he doesn't spend 300 hours over-analyzing code that doesn't actually matter?
*was lead dev
breakpoint shouldn't be string. should use guards in the getSize method, to make it smaller, and better microperformance. his current method does useless if checks. for every case it will do 4 if checks.
also, no way TS doesn't throw errors. Sizemap can't just accept any number, he probably did {[key: number]: any}
also,why the frick is the return type number lol, why does he need to lookup the sizemap to get a number back..
AI would write better code 100%
>lead dev
>8k a month usd
i hope that's post tax or only the base salary lol
>js
>dev
no
looks pretty shitty, OP
export const getSize = (columnCount : number, breakpoint: string): number => {
var size;
if (columnCount < 3) {
size = 3;
} else if ( columnCount < 5) {
size = 4;
} else if ( columnCount < 7) {
size = 6;
} else {
size = 12;
}
return SizeMap[size][breakPoint];
};
Code quality isn't the primary feature of a lead dev. A lead dev is someone who can develop project requirements and execute on those requirements in a timely fashion and deliver an acceptable product, lead devs also are capable of mentoring junior devs and able to communicate to management.
My main gripes with that code is the lack of comments, lack of new lines, and doing multiple tasks on single lines. This type of code will be prone to bugs and is a pain in the ass to debug weeks or months down the road.
all javascript code looks like trash, how can you tell if it's bad or not?
the only major offense I have is the Object.keys call, it screams chatgpt assisted code
I use that all the time, even before chatgpt was released. How else would you get the keys from an object?
for (key in object) {
you get what you pay for
stop cheaping out