I love when you explain in detail why these advices are not so good, it is really helpfull especially for begginers that could get into this errors and not know the cause or how to solve them. I think this is a great idea for a series and I'm willing to watch them all, keep up the good work!
As for automapper... I think the real issue is people add it for some use-case that makes sense, and then because it's there, they end up mapping everything they have through it, instead of just the one thing that actually needed it. Automappers destroy compile-time type safety when you use them, they should be used *extremely* sparingly, and only in cases where their test-validation can work (i.e, fully maps either input or output). If you have to define the mapping because it's not 1:1 with the same names, it's easier/faster/safer to just define those mappings in normal code, manually
Yeah, I even went to the rabbit hole of doing my own reflection/attribute automapper... spent hours on it, then forgot all the time how it worked. Rule of thumb for me now: if you are likely to use automapper, you probably should create a list of specific items instead of properties.
I've been advising against AutoMapper since the day I first saw it. I don't even care about the performance, the profiles that you have to write are often more verbose than writing the mapping code yourself, nothing 'Auto' about it. And next to what you mentioned, good luck finding an error in your mapping profile since they're impossible to debug properly. To make matters worse, developers end up putting all sorts of business logic in the mapping profiles, which makes the code a nightmare to maintain. Jimmy Bogard himself says AutoMapper shouldn't be used like this, and should only be used for simple use-cases in which the classes are basically the same, but why did he add the possibility to do all these things :(?! Writing a custom mapper, or using a static CreateFrom method on the class to map to are the ways to go IMO. There's even tools to generate mapping classes for you...
Also, the advice used Automapper 4 from 2015, whereas the current version is 12. So it could just be horribly outdated, which is often the case for such “advises”.
Regarding AutoMapper, the creator himself has said that it was only intended to be used for simple cases, and that people often use it in complex scenarios where it shouldn't be. The guidance, therefore, might be to only use AutoMapper when your mappings are so simple that you don't need AutoMapper.
I absolutely agree with each and every point you're making. 7:30 In c++ there was a time where everything had to be as unreadable as possible where single letters was used everywhere as variables. I C# it seems like its the other way around where everyting has to be spelled out and be as readable as possible. I like the middelground where the two are mixed. Like with var student = new Student(); and in plural if it's a list of a collection. In lambdas I try to use the first letter of the class or collection I'm accessing. Like with students.Where(s => s) instedet of x => x. etc etc. In a foreach I'd like to have foreach(var student in students) but have used foreach(var stud in students) as well at times.
Love the series idea! Nice pointing out the “trust me bro” problem. Since we are trying to minimize the problem of trusting whatever you see on the internet ( no offense but untrained eyes don’t know if you are right either), could you reference the official documentation, which would fit the httpClient example.
Good stuff Nick, especially around naming. It's really not that hard as code should read like prose, and using proper names for vars and args helps you fall into the pit of succes.
When I'm naming lambdas params, you're right, it's HIGHLY context sensitive. I always chose something contextually relevant to what I'm dealing with. If it's a student, param name would be s. If it's an address a. But if I were working on an order system and dealing with agencies and advertisers, I would likely not use "a" in favor of agy or adv as the param names. And this would happen even if they're not being both used in the same lambda. The little bit of extra context ensures that I know what object I'm dealing with without having to scan back to the start of the lambda. So yea... great advice. HIghly context sensitive. Anyone who has a silver bullet answer for that question is wrong.
world would be better place if people followed that, it's really not that hard. And yet what does Nick say about it? 'Oh I use x,y,z and I think it's fine'. FFS...
4:20 biggest take-away from this is the worst one is still measured in microseconds, so performance is probably not what you should be deciding based on, unless your context is extreeemely performance-sensitive (in which case you're often better off just descending to C).
Many coders tend to blindly follow rules without considering the reason for the rule in the first place. Always be flexible and understand context. This actually applies in all areas of life. There are countless blogs out there that cry about OOP, citing specific scenarios where it's ugly and difficult. Well...don't use OOP principles in EVERY SITUATION! Same can be said regarding functional programming. Functional programming has some nice benefits...but strict adherence can put you into ugly situations as well. How many teams use scrum on EVERY PROJECT even when it makes no sense for a particular project simply because they are blindly following a methodology? You highlighted the phrase "it depends"...this phrase is key to everything in tech.
I prefer manual mapping just because it gives me more control and, to be honest, it's faster to understand something. It's clearer, no magic, no shenanigans. No issues with Automapper, I just prefer not to, it doesn't really make sense to me, specially with records and required properties now.
Good points! I will say I prefer the LINQ lambda variable short-hand for more compact code (i.e. `students.Where(s => s ...)`). However, I take it one OCD step further with the use of `x` as my lambda only when I'm dealing with a projection of something (i.e. an EF `.Join()`) or the list name actually begins with the letter `x` (i.e. `var xrays = new List();`)... and if I'm doing multiple projections, I'll start using `x0`, `x1`... Good stuff man! Keep it up.
I really like the video format, Nick. Keep going! I used to see a lot of posts like these ones on LinkedIn, some trying to state things no matter the context, something like "here's the universal truth, accept it". 🥴
This reminds me of Sabine Hossenfelder's advice about statistics in science: "Never trust a statistic without a confidence interval, especially in psychology."
We had Auto mapper in heavy use a long time ago in a project far far away. Auto mapper was one of the biggest bottle necks that the code was experiencing. We had to rip it out and replace it with manual mappings. This was years ago, and every code base is different so ymmv
Great idea, worth spreading. I was really surprised that someone else is using x in lanbdas! Super! One piece of advice only, do not mix three topics, every one deserves even a short, but separate video. Anyway, thank you very much for sharing.
Before writing to response in middelware or execute next middelware in the pioeline you must check if response is not started to be written. There is a boolean for that - read do about middelware.
Thank you for bringing up the point of general usage versus context sensitive usage. It would be like a carpenter saying never use a hammer, even when using a hammer makes perfect sense. I feel like a lot of advice falls into general usage compared to: use this pattern or process when X occurs.
I'm a believer in using meaningful names, but I also agree with Lambda using the one letter/short name that makes sense is a good way to maintain readability
This is a great example of why AI cannot take over. It still takes skill to analyze the answers it gives you because it could pull code from a post such as these
Posts like this actually make the AI worse by muddying up the training data with false information. Then again, posts like this make human developers worse too...
The only comment I can make that could have been improved on the "trust me bro" comment was for you to provide a link in the video description for your video to give context to the performance metrics you have for the mappers
My biggest gripe with Automapper or other mapper libs is MAINTAINABILITY. I've worked in huge codebases where Automapper is used prevalently, it's absolute hell trying to figure out who calls who. Especially so if Mediatr is involved. Why do it? It might feel good not having to write the mapping code, saving 30 seconds (*cough* Copilot), but any time you save will be absolutely trounced when you have to come back and change it or staff churns.
Agree about expressions/delegates syntax, but I usually use 'e' as shortcut (entity), but when you have inner closures (lambda inside lambda) I am already trying to give some names which make sense (as you would have it overlapped by parameter name, and at some cases you don't want that).
I've started to use a IMappingDefinition interface, that is injected, and it's either a manual mapping or I might inject IMapper into it, but I am spending too much time trying to make mappings in Automapper that isn't well suited for it, so I'm giving up
If I have a Species object, what do I call a list of these if I can't say speciesList? Now we have a naming exception and inconsistency in the application code. Postpending List, Collection, etc. should therefore be the preferred method.
Good video man. While I do not use Automapper or any mappers but rather just write mappers myself, I can see why it might be appealing for some use cases - As usual, context is king, and there's no one-size-fits all I suppose.
I have encountered a lot of people saying that "you should always do this, and not that" without context. Experienced developers should understand context, and not give this kind of advice to others.
I personally don’t like the random single letters. I’m completely fine with “x” however, as that is a “convention”. I always first scan read blocks of code, and “x” acts as an anchor. “m” or “e” or “o” or other random letter is just random. I’m also only really using “x” when there is a single expression
Heavily believe that why it maybe matters a bit which mapping tool to use, but much more important is, how that thing then gets used. Learned the hard way to not put any BL in the mapping^^ Mapper setup in a mapping method is was also quite amusing to see. At least I never made that mistake :)
Naming variables is never a problem. The order of difficulty goes like this, IMO (easiest first). Variable Field Argument Property Method Enum Class/struct Interface Namespace Solution Which is similar to how much work it is to change it too, so that's great, I guess 😢.
I never understood why in lambdas it was ok to use a one letter variable. If it expands too much to the right with the full name, maybe it's time to: - extract the method, and then you can remove the parameter completely at the calling point which is nice or - add a method to the student so you end up just calling this and it should be short and readable or - add an extension to the IEnumerable or IQueryable because when isolated it's ok to have more detailed code or - I'm sure there are other techniques to move the code that does the job and only leave method calls here that only expose WHAT is going on instead of HOW it's done. As for the studentList, if at one point you need to change its type for example to an Array for whatever reason, the variable name is suddenly lying to the reader and you would need to rename it. Depending on the scope of the variable, this could be annoying.
I agree with single character in Linq variable and my preference is always use the first letter of alphabet `a`, so not to overthink it. :D. Modern IDE can also show the type easily by just hovering your mouse at the variable.
Should start with sirens 🚨 😮 . We went with a homebrewed mapper... and now we are tearing it out and going full manual mapping due to new requirements... should have started as manual.
Your channel has several problems: the videos are too short and you publish few of them. 😄 This is not an accusation, your content is absolutely EXCELLENT. But I would like many more 😂. Great job Nick
I have to chuckle at the benchmark provided for AutoMapper in that screenshot given that the version number is so incredibly old as to be completely irrelevant. I agree with you that any programming advice given on LinkedIn, and even StackOverflow for that matter, needs to be taken with a grain of salt and carefully evaluated before it is adopted wholesale into one's codebase.
Some of these seem like they may fit really well also as a community poll/quiz thing, which (if I understand correctly) can help drive channel engagement?
I do like studentList over students. I always show if it's some type of list. A obj, what ever it is, and saying it's a list of them. What if student was a lot of students, that is we getting a list of studentList and adding them to a list, so we would then have studentsList.
That middleware looks suspicious. It looks like it will call take request's URL, do another request to that URL and thus keep looping. I'll need to check it when I have time.
It's interesting how much "advice" we can get on linkedin, yet so little is actually useful :) About naming, one-letter names are not neccessarily bad in my oppinion - if the reader is expected to understand them! If you are implementing an algorithm from a mathematics paper, for instance, then it would probably be very confusing for the reader if the symbols had totally different names in the code. If you are doing statistics calculations then "p" should be a perfectly valid name for a variable, or if you are doing linear algebra, then "i", "j" and "k" are common when denoting matrix multiplication etc. So at least in a context where short names already have a conventional meaning it should be ok, or even preferred I think!
The one that will fix a bug in your code or optimize it will not know "statistics calculations". p is worthless as a name. Single letter is often used in many contexts in math and physics, good luck finding which one that single letter is . Will searching "p" in google help you understand what that fuck it is?
I'm just amazed that there is an automapper to begin with. It feels like a solution in search of a problem. I toss it in the stupid library pile along with Java's lombok.
Just as a quick aside, I wish your site had prices in USD as well so I can see what it would be plus the international taxes and currency exchange fees I gotta pay.
I guss you should showcase the person as well, who posting wrong (unknowingly or knowingly) things, so that they can think twice and validate before posting it.
The new Automapper has improved a lot and the differences are not so different. It utilizes expression chains which are precompiled and does not use reflection or expression generation at run time like in the older versions.
Wow. I need to pay better attention to what people are posting on LinkedIn so I can take them to school. That middleware screenshot made my eye twitch.
Name this series CPD, Code Police Department and it's going to take off like a rocket
I like these series already, as I liked the other debunk videos. A great way to explain to colleagues why not to do certain things.
I love when you explain in detail why these advices are not so good, it is really helpfull especially for begginers that could get into this errors and not know the cause or how to solve them. I think this is a great idea for a series and I'm willing to watch them all, keep up the good work!
As for automapper... I think the real issue is people add it for some use-case that makes sense, and then because it's there, they end up mapping everything they have through it, instead of just the one thing that actually needed it. Automappers destroy compile-time type safety when you use them, they should be used *extremely* sparingly, and only in cases where their test-validation can work (i.e, fully maps either input or output). If you have to define the mapping because it's not 1:1 with the same names, it's easier/faster/safer to just define those mappings in normal code, manually
Yeah, I even went to the rabbit hole of doing my own reflection/attribute automapper... spent hours on it, then forgot all the time how it worked. Rule of thumb for me now: if you are likely to use automapper, you probably should create a list of specific items instead of properties.
I've been advising against AutoMapper since the day I first saw it. I don't even care about the performance, the profiles that you have to write are often more verbose than writing the mapping code yourself, nothing 'Auto' about it. And next to what you mentioned, good luck finding an error in your mapping profile since they're impossible to debug properly. To make matters worse, developers end up putting all sorts of business logic in the mapping profiles, which makes the code a nightmare to maintain. Jimmy Bogard himself says AutoMapper shouldn't be used like this, and should only be used for simple use-cases in which the classes are basically the same, but why did he add the possibility to do all these things :(?!
Writing a custom mapper, or using a static CreateFrom method on the class to map to are the ways to go IMO. There's even tools to generate mapping classes for you...
I agree with you Nick! And I use automapper a lot, works for my cases..
Also, the advice used Automapper 4 from 2015, whereas the current version is 12. So it could just be horribly outdated, which is often the case for such “advises”.
Regarding AutoMapper, the creator himself has said that it was only intended to be used for simple cases, and that people often use it in complex scenarios where it shouldn't be.
The guidance, therefore, might be to only use AutoMapper when your mappings are so simple that you don't need AutoMapper.
I absolutely agree with each and every point you're making. 7:30 In c++ there was a time where everything had to be as unreadable as possible where single letters was used everywhere as variables. I C# it seems like its the other way around where everyting has to be spelled out and be as readable as possible. I like the middelground where the two are mixed. Like with var student = new Student(); and in plural if it's a list of a collection. In lambdas I try to use the first letter of the class or collection I'm accessing. Like with students.Where(s => s) instedet of x => x. etc etc. In a foreach I'd like to have foreach(var student in students) but have used foreach(var stud in students) as well at times.
Love the series idea! Nice pointing out the “trust me bro” problem. Since we are trying to minimize the problem of trusting whatever you see on the internet ( no offense but untrained eyes don’t know if you are right either), could you reference the official documentation, which would fit the httpClient example.
I love this, this series has so much potential
Good stuff Nick, especially around naming. It's really not that hard as code should read like prose, and using proper names for vars and args helps you fall into the pit of succes.
When I'm naming lambdas params, you're right, it's HIGHLY context sensitive. I always chose something contextually relevant to what I'm dealing with. If it's a student, param name would be s. If it's an address a. But if I were working on an order system and dealing with agencies and advertisers, I would likely not use "a" in favor of agy or adv as the param names. And this would happen even if they're not being both used in the same lambda. The little bit of extra context ensures that I know what object I'm dealing with without having to scan back to the start of the lambda. So yea... great advice. HIghly context sensitive. Anyone who has a silver bullet answer for that question is wrong.
world would be better place if people followed that, it's really not that hard. And yet what does Nick say about it? 'Oh I use x,y,z and I think it's fine'. FFS...
4:20 biggest take-away from this is the worst one is still measured in microseconds, so performance is probably not what you should be deciding based on, unless your context is extreeemely performance-sensitive (in which case you're often better off just descending to C).
Love your benchmarking comparisons. Would love to see more
I also use one letter in Linq for 95% of the times. Other 5 if the list or action or func is not obvious enough.
Great videos as always :)
Many coders tend to blindly follow rules without considering the reason for the rule in the first place. Always be flexible and understand context. This actually applies in all areas of life.
There are countless blogs out there that cry about OOP, citing specific scenarios where it's ugly and difficult. Well...don't use OOP principles in EVERY SITUATION! Same can be said regarding functional programming. Functional programming has some nice benefits...but strict adherence can put you into ugly situations as well. How many teams use scrum on EVERY PROJECT even when it makes no sense for a particular project simply because they are blindly following a methodology? You highlighted the phrase "it depends"...this phrase is key to everything in tech.
I prefer manual mapping just because it gives me more control and, to be honest, it's faster to understand something. It's clearer, no magic, no shenanigans.
No issues with Automapper, I just prefer not to, it doesn't really make sense to me, specially with records and required properties now.
7:27 "There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton
Good points! I will say I prefer the LINQ lambda variable short-hand for more compact code (i.e. `students.Where(s => s ...)`). However, I take it one OCD step further with the use of `x` as my lambda only when I'm dealing with a projection of something (i.e. an EF `.Join()`) or the list name actually begins with the letter `x` (i.e. `var xrays = new List();`)... and if I'm doing multiple projections, I'll start using `x0`, `x1`... Good stuff man! Keep it up.
Going through the Docker course right now, excellent so far. Keep up the good work!
Keep it up. It was a great post and I'm waiting to watch his kind of videos again!
I really like the video format, Nick. Keep going!
I used to see a lot of posts like these ones on LinkedIn, some trying to state things no matter the context, something like "here's the universal truth, accept it". 🥴
This reminds me of Sabine Hossenfelder's advice about statistics in science: "Never trust a statistic without a confidence interval, especially in psychology."
We had Auto mapper in heavy use a long time ago in a project far far away. Auto mapper was one of the biggest bottle necks that the code was experiencing. We had to rip it out and replace it with manual mappings.
This was years ago, and every code base is different so ymmv
Automapper was redesigned using precompiled expression chains which has made it drastically faster and even faster than some other libraries.
The preview picture of the video is🔥
Great idea, worth spreading. I was really surprised that someone else is using x in lanbdas! Super! One piece of advice only, do not mix three topics, every one deserves even a short, but separate video. Anyway, thank you very much for sharing.
Nice format, please continue
Before writing to response in middelware or execute next middelware in the pioeline you must check if response is not started to be written. There is a boolean for that - read do about middelware.
Thank you for bringing up the point of general usage versus context sensitive usage. It would be like a carpenter saying never use a hammer, even when using a hammer makes perfect sense.
I feel like a lot of advice falls into general usage compared to: use this pattern or process when X occurs.
I'm a believer in using meaningful names, but I also agree with Lambda using the one letter/short name that makes sense is a good way to maintain readability
This is a great example of why AI cannot take over. It still takes skill to analyze the answers it gives you because it could pull code from a post such as these
Posts like this actually make the AI worse by muddying up the training data with false information. Then again, posts like this make human developers worse too...
Woop-woop, that's the sound of .NET police!!!
You really missed the police cap))) Thanks for videos!)
Spot on!
The only comment I can make that could have been improved on the "trust me bro" comment was for you to provide a link in the video description for your video to give context to the performance metrics you have for the mappers
I like the start of that serie - i would like of you would keep doing that
Very nice series Nick!
My biggest gripe with Automapper or other mapper libs is MAINTAINABILITY. I've worked in huge codebases where Automapper is used prevalently, it's absolute hell trying to figure out who calls who. Especially so if Mediatr is involved. Why do it? It might feel good not having to write the mapping code, saving 30 seconds (*cough* Copilot), but any time you save will be absolutely trounced when you have to come back and change it or staff churns.
Agree about expressions/delegates syntax, but I usually use 'e' as shortcut (entity), but when you have inner closures (lambda inside lambda) I am already trying to give some names which make sense (as you would have it overlapped by parameter name, and at some cases you don't want that).
Good series content! Perhaps later expand them to some antipatterns and gotchas in various scenarios!
Good advice. Thank you Nick
This is a great video! And I agree with your statements here.
I've started to use a IMappingDefinition interface, that is injected, and it's either a manual mapping or I might inject IMapper into it, but I am spending too much time trying to make mappings in Automapper that isn't well suited for it, so I'm giving up
Great video, thanks for sharing!
Good tips, thanks Nick.
I think I'll love this series
If I have a Species object, what do I call a list of these if I can't say speciesList? Now we have a naming exception and inconsistency in the application code.
Postpending List, Collection, etc. should therefore be the preferred method.
Good video man. While I do not use Automapper or any mappers but rather just write mappers myself, I can see why it might be appealing for some use cases - As usual, context is king, and there's no one-size-fits all I suppose.
I strongly recommend Mapperly, it's almost like writing your own mapper, but actually you don't have to
Perfect video as usual
I have encountered a lot of people saying that "you should always do this, and not that" without context.
Experienced developers should understand context, and not give this kind of advice to others.
Startup class is a preference.
I agree with Nick
Good video, thanks!
Now I want to join the LAPD workforce but I never get C# “tips” on my LinkedIn feed. What do I need to follow to get these bad advices?
hey @nick do you have a bundle deal for all 3 new courses?
Nick, could you shed some light on the ConfigureAwait(false) topic?
I personally don’t like the random single letters. I’m completely fine with “x” however, as that is a “convention”.
I always first scan read blocks of code, and “x” acts as an anchor. “m” or “e” or “o” or other random letter is just random.
I’m also only really using “x” when there is a single expression
Heavily believe that why it maybe matters a bit which mapping tool to use, but much more important is, how that thing then gets used.
Learned the hard way to not put any BL in the mapping^^
Mapper setup in a mapping method is was also quite amusing to see. At least I never made that mistake :)
As a LinkedIn court I find these posts with invalid benchmarks guilty and I order the author of the post - 3 months in home arrest with clean coding!
students is better than studentList because you make further refactoring easier if for instance you change the list to array or ienumerable
Naming variables is never a problem.
The order of difficulty goes like this, IMO (easiest first).
Variable
Field
Argument
Property
Method
Enum
Class/struct
Interface
Namespace
Solution
Which is similar to how much work it is to change it too, so that's great, I guess 😢.
I agree with your opinion 100% 👍
Cool idea for a series.
I never understood why in lambdas it was ok to use a one letter variable.
If it expands too much to the right with the full name, maybe it's time to:
- extract the method, and then you can remove the parameter completely at the calling point which is nice
or
- add a method to the student so you end up just calling this and it should be short and readable
or
- add an extension to the IEnumerable or IQueryable because when isolated it's ok to have more detailed code
or
- I'm sure there are other techniques to move the code that does the job and only leave method calls here that only expose WHAT is going on instead of HOW it's done.
As for the studentList, if at one point you need to change its type for example to an Array for whatever reason, the variable name is suddenly lying to the reader and you would need to rename it. Depending on the scope of the variable, this could be annoying.
Oh hell yeah! You go Nick! 😂
lol nice series name 👍
thank you for all knowledge you share!
these series are really interesting and promising.
Yup great advice, keep it up!
We have been using AutoMapper in 10years now.
If we had 4 seconds in mapping, I'm sure that we had replace it for long time ago 😂
I agree with single character in Linq variable and my preference is always use the first letter of alphabet `a`, so not to overthink it. :D. Modern IDE can also show the type easily by just hovering your mouse at the variable.
Should start with sirens 🚨 😮 .
We went with a homebrewed mapper... and now we are tearing it out and going full manual mapping due to new requirements... should have started as manual.
What about cqrs? I see new templates including this thing call mediatr.
So mapping objects manually is the fastest way?! 😮 Didn't know this. Thanks Nick.
Did anyone else notice the version of Automapper used in that benchmarking graph? We're at version 12 now!
I like this series!
Boutta catch a case writing my silly little code, doing silly little things
Your channel has several problems: the videos are too short and you publish few of them. 😄 This is not an accusation, your content is absolutely EXCELLENT. But I would like many more 😂. Great job Nick
Several problems?
@@alexisfibonacci I'm joking of course. It was to say that I'm addicted to his videos and I always want more
I have to chuckle at the benchmark provided for AutoMapper in that screenshot given that the version number is so incredibly old as to be completely irrelevant. I agree with you that any programming advice given on LinkedIn, and even StackOverflow for that matter, needs to be taken with a grain of salt and carefully evaluated before it is adopted wholesale into one's codebase.
Some of these seem like they may fit really well also as a community poll/quiz thing, which (if I understand correctly) can help drive channel engagement?
Waiting for next LAPD#002 already.
Nice series ideas Nick.
An idea is also to have good examples series from X:D
So, the coder who created tinymapper wants to get more exposure to that package?
I do like studentList over students. I always show if it's some type of list. A obj, what ever it is, and saying it's a list of them.
What if student was a lot of students, that is we getting a list of studentList and adding them to a list, so we would then have studentsList.
Just like lambdas I only use var if the object is identifiable on the right
That middleware looks suspicious. It looks like it will call take request's URL, do another request to that URL and thus keep looping. I'll need to check it when I have time.
everything is cool as always
It's interesting how much "advice" we can get on linkedin, yet so little is actually useful :) About naming, one-letter names are not neccessarily bad in my oppinion - if the reader is expected to understand them! If you are implementing an algorithm from a mathematics paper, for instance, then it would probably be very confusing for the reader if the symbols had totally different names in the code. If you are doing statistics calculations then "p" should be a perfectly valid name for a variable, or if you are doing linear algebra, then "i", "j" and "k" are common when denoting matrix multiplication etc. So at least in a context where short names already have a conventional meaning it should be ok, or even preferred I think!
The one that will fix a bug in your code or optimize it will not know "statistics calculations". p is worthless as a name. Single letter is often used in many contexts in math and physics, good luck finding which one that single letter is . Will searching "p" in google help you understand what that fuck it is?
Perfect Nick
Done!
I'm just amazed that there is an automapper to begin with. It feels like a solution in search of a problem. I toss it in the stupid library pile along with Java's lombok.
Wow. It's so cool
Just as a quick aside, I wish your site had prices in USD as well so I can see what it would be plus the international taxes and currency exchange fees I gotta pay.
for param linq with simple where I like to use "it" as name like it's done by default in kotlin
I guss you should showcase the person as well, who posting wrong (unknowingly or knowingly) things, so that they can think twice and validate before posting it.
The new Automapper has improved a lot and the differences are not so different. It utilizes expression chains which are precompiled and does not use reflection or expression generation at run time like in the older versions.
scary thumbnail :D ... but good material
I thought that Automapper gone Moq way.
That's literally the subject of the video and the claim of the first piece of advice
@@nickchapsas agree...and as i said good stuff! i'll refactor comment as now i see it can be interpreted several ways
The "Pay with GPay" button seems broken on Dometrain :( cannot buy the course
Nick Chapsas! Can you please wear chaps for your next video?
Wow. I need to pay better attention to what people are posting on LinkedIn so I can take them to school. That middleware screenshot made my eye twitch.
With the naming of objects students.Where(s => s .... );
I use underscores, Is it a bad approach? eg students.Where(_ => _.HasStartedSchooling);
I totally agree with the student naming. It is stating the obvious twice. Unfortunately, its on our code naming standard (sigh)
Good 101 advice.