|
It is pretty amazing sometimes - takes a bit of getting used to but it can really speed up your code.
But even for a quick'n'dirty, that's rather long winded - especially if it's a long string as ToCharArray allocates memory and copies string content into it. You can index directly into a string, remember?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It is amazing... until it is not...
Wait and see - after enough suggestions you will find that most of them are plain stupid repetition of what you done before (a true no-brain op)...
“Real stupidity beats artificial intelligence every time.”
― Terry Pratchett, Hogfather
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: Wait and see - after enough suggestions you will find that most of them are plain stupid repetition of what you done before (a true no-brain op)...
I had more obviously wrong suggestions than cases where it generated what I wanted, but that's not why I turned it off after a few weeks.
I pulled the plug because about 5-10% of the suggestions were dangerously wrong. Things that looked OK at first glance, but which had subtle logic errors in them. Trying to debug my own wrong think is bad enough, when the code running is ever so slightly off of what I intended was far worse.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
I've found that most of the suggestions (80%+) are exactly what I wanted to do. I've been pretty wowed by the technology. Maybe it's because it's looking over my shoulder and learning from a truly great programming master 
|
|
|
|
|
80% of my code is "plain stupid repetition of what [I've] done before"
|
|
|
|
|
|
Quote: This IDE can read my code and comments and predict the next if statement.
I`m not using VS 2022, a feature like that belongs to the realm of SF, really. Very original. Of course old fashion people (me included) might display appreciation towards this advancement in intellisense/autocomplete but will never actually use it in their projects.
|
|
|
|
|
You might be surprised - it's actually pretty good. I'm not young - 63 - but I'm finding it handy to "fill in the blanks" with the drudge stuff: it works out what they heck you are likely to be trying to do and provides a default text that uses sensible variables you used earlier and suchlike. It does appear to use the variable names to help it decide as well, which is a damn good reason for using sensible names at all times instead of "quick to type" ones ... 
Give it a try (the Community edition is free so there's not a lot of excuse) - it might surprise you! (It did me.)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I use it for my hobby projects Paul and find it good - but I've never known a bad release of VS
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
nice, soon you will only need to write the first half of your program, the IDE will figure out the other half on his own
|
|
|
|
|
It's not quite that good, but if you do something like this:
var bananas = Fruit.GetFruits(Color.Yellow); Then later in the method type foreach(it will autofill with this:
foreach(var f in bananas) If (as I much prefer) you use an explicit type:
List<Fruit> bananas = Fruit.GetFruits(Color.Yellow); Then the autofill is explicit as well:
foreach(Fruit fruit in bananas) All on a single TAB press.
Once you are used to it, it takes the typing out of the simple stuff, and it leaves you free to concentrate on the "why" you are doing it, instead of the "what".
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It comes a bit difficult to think in C# terms but I`ll try
How about the situation when you have so many fruits that they won`t fit in a single list. We are talking about a huge amount of fruits, all of the same type. So you would have to use lists of lists or lists of lists of lists.
List<List<Fruit>> lemons = Fruit.GetFruitsLists(Color.Yellow);
can autocomplete deal with that?
[edit]
ok it`s a bit of a wild guess on my behalf, I just don`t know if what I`m saying is correct but if you have a huge number of fruits, all of them rather small in dimension would you keep a single list containing all of them thus resulting a huge solid blob of memory difficult to maneuver, or, second option, partition them into multiple lists which would make a more flexible solution from the memory usage perspective.
modified 16-Aug-22 14:43pm.
|
|
|
|
|
I would suspect so, but I'm on a tablet at the moment, and don't have VS 2022 installed on it.
I'll check tomorrow when I'm back on the desktop.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The edited bit ...
Whoo, that's a complicated one ... Lists are pretty efficient at what they do, but it depends on what you actually do with them - this may help: List<T> - Is it really as efficient as you probably think?[^]
So a List of Lists (of lists) could be more efficient than a monolithic list. Or it could be massively inefficient if you use it badly. But remember that as it's a class the collection(s) are storing, the memory occupied is the same whether it's an instance or a collection that it holds - the memory for the actual instance will be exactly the same size and number regardless, so nested collections may take up slightly more memory than a single one because of the extra references to collections involved. But only if you let the big one grow to size - otherwise the "double each time it's full" part of the equation starts to consume inordinate amounts of memory (and processing time to copy across as it goes).
But then when you use it, the flat model outperforms in it terms of processing, because there is less dereferencing going on.
And if you start storing the Fruit as a struct rather than a class to save space and dereferencing, you introduce a whole new kettle of fish because the size of the Fruit starts to impact space and processing when you copy it each time (value types) instead of copying the reference alone. And ... there is a limit on the size of the monolithic collection because of the .NET limit on max size of any one item, and an array of structs is a single chunk of memory n * sizeof(Fruit) bytes long instead of n * 4 or n * 8 bytes long for an array / list of references. Again, this might help: Using struct and class - what's that all about?[^]
It's never as simple as it seems, is it?
[edit]
Second link changed - I forgot to CTRL+C before pasting ... 
[/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
modified 16-Aug-22 16:18pm.
|
|
|
|
|
Thanks for explaining
Quote: Second link changed - I forgot to CTRL+C before pasting ...
just noticed your edit. I think public logging of edit time would make a nice CP feature.
modified 17-Aug-22 21:29pm.
|
|
|
|
|
Calin Cali wrote: I think public logging of edit time would make a nice CP feature.
You mean like the "modified 20hrs ago." text at the bottom of the message?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Quote: You mean like the "modified 20hrs ago."
(only if you knew what you are talking about)
yeah, with a small font and in brackets.
modified 17-Aug-22 12:37pm.
|
|
|
|
|
Interestingly, if you use var it copes quite well.
If you use an explicit type, it doesn't suggest anything.
And now, a few minutes later it doesn't cope at all ... but the GetFruits example yesterday does ... VS has just updated itself, that may be the reason.
I'll try a shut down and restart of the whole PC to clear out any "old bits" it may still have running later.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I've never had so much data that I had to be concerned with splitting my List<> objects. However, I have had a need for List<list<>> before because of the nature of the data. Think of the outer list being for all car manufacturers while each inner list is for each car model they make. Because of how my database data was structured, this made more sense at the time. I could have used linq to combine all car lists into a single list, but it wasn't necessary.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Quote: Think of the outer list being for all car manufacturers while each inner list is for each car model they make
Yeah you could push that logic even further by making 'car model' a list on its own containing all the car model parts (for a car service shop use for instance). List in a list saves you sorting time but a list is just a container it doesn`t provide any clue about what`s inside other than it`s name so you need to keep a separate account about the list tree structure, levels if the tree is rather deep/complex.
|
|
|
|
|
I this thing does everything for you soon no knowledge of programing will be required to write a program.
|
|
|
|
|
There are plenty of people who already think that is true.
|
|
|
|
|
There are enough people trying to produce code without any knowledge or thought already: check out QA some day ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The {get; set;} auto-complete is great, and yes, the prediction is 80% amazing and 20% annoying in my experience. And the annoying isn't too annoying.
dan!sh wrote: I really do not care about code quality. This is a one time use (quick or slow) and dirty utility.
Well, in my experience, paying attention to code quality, no matter the requirements, always pays off.  Converting the string to a char array and then iterating over it with a for loop is a bit like walking away from the pilot seat without setting the auto-pilot.
|
|
|
|
|
Perhaps you or someone else can explain this {get; set;} thing to me. There are times when having a getter is appropriate, but far fewer times when having a setter is appropriate. I'm surprised that they make it so easy to mindlessly provide one.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
