Why did I do that?
-
I'd like to call a hall of shame on myself - or, rather, my coding practices of about six years ago. Having just jumped into .NET, I was building a periodic table. I (manually) serialized the element data in a double-separated string (I think the separators were | for elements and ; for each of their attributes). The only problem was, I'd never heard of String.Split. I'd implemented a one-separator splitter once before using String.Substring, but the two-separator splitter was far more complex. About six hours of coding later, I had around thirty lines of String.Substring (if I still had the files, I would paste in the function). It worked, but looking back, I realize I could have replaced all that with a single line. Live and learn, I suppose.
-
I'd like to call a hall of shame on myself - or, rather, my coding practices of about six years ago. Having just jumped into .NET, I was building a periodic table. I (manually) serialized the element data in a double-separated string (I think the separators were | for elements and ; for each of their attributes). The only problem was, I'd never heard of String.Split. I'd implemented a one-separator splitter once before using String.Substring, but the two-separator splitter was far more complex. About six hours of coding later, I had around thirty lines of String.Substring (if I still had the files, I would paste in the function). It worked, but looking back, I realize I could have replaced all that with a single line. Live and learn, I suppose.
That happens to everyone. When I started with WinForms the first thing I did was write a nice class for linked lists. And then had my facepalm moment when I discovered the the System.Collections namespace :) To my defense: I used to work with C++ before and was used to be on my own for such things. Still, the class did its job and was a nice exercise to get used to managed references and garbage collection. And it gave me some impression about what kind of performance to expect from managed code.
At least artificial intelligence already is superior to natural stupidity
-
I'd like to call a hall of shame on myself - or, rather, my coding practices of about six years ago. Having just jumped into .NET, I was building a periodic table. I (manually) serialized the element data in a double-separated string (I think the separators were | for elements and ; for each of their attributes). The only problem was, I'd never heard of String.Split. I'd implemented a one-separator splitter once before using String.Substring, but the two-separator splitter was far more complex. About six hours of coding later, I had around thirty lines of String.Substring (if I still had the files, I would paste in the function). It worked, but looking back, I realize I could have replaced all that with a single line. Live and learn, I suppose.
A lot of folk come to C# from some other language and they "already know how to program" so they don't look for how a task should be done. When starting with C# it is helpful to research how a task can be done with .NET rather than doing it the old C, C++ or Java way.
Just because the code works, it doesn't mean that it is good code.
-
A lot of folk come to C# from some other language and they "already know how to program" so they don't look for how a task should be done. When starting with C# it is helpful to research how a task can be done with .NET rather than doing it the old C, C++ or Java way.
Just because the code works, it doesn't mean that it is good code.
I would say that being able to solve problems on their own demonstrated very well that they indeed do know how to program and their results document the range of their knowledge. If I had a choice between an experienced programmer who never has seen the .Net framework and another one who has memorized the MSDN and all 'best practices', but then is helpless when something outside his beaten path happens, then I sure know which one I will hire. Frameworks and 'best practices' are nice and well. They can save you much time. They also mean that you have left the thinking to others. You have not invested much thought in the problem. You have not run into problems. You have not analyzed and solved the problem. And you have not gained much experience. From the perspective of bosses and money counters a cheap, well trained code monkey that gets the job done with a bit of luck and some prayers of course is the better deal.
At least artificial intelligence already is superior to natural stupidity
-
I'd like to call a hall of shame on myself - or, rather, my coding practices of about six years ago. Having just jumped into .NET, I was building a periodic table. I (manually) serialized the element data in a double-separated string (I think the separators were | for elements and ; for each of their attributes). The only problem was, I'd never heard of String.Split. I'd implemented a one-separator splitter once before using String.Substring, but the two-separator splitter was far more complex. About six hours of coding later, I had around thirty lines of String.Substring (if I still had the files, I would paste in the function). It worked, but looking back, I realize I could have replaced all that with a single line. Live and learn, I suppose.
-
A lot of folk come to C# from some other language and they "already know how to program" so they don't look for how a task should be done. When starting with C# it is helpful to research how a task can be done with .NET rather than doing it the old C, C++ or Java way.
Just because the code works, it doesn't mean that it is good code.
If only I can use a DE with a serious autocompletion, then if I don't know an API yet, I press a "
." (dot) and examine all methods to find out if there is a ready to use solution for my problem. By the way I learn API, and after n times doing this operation, I catch up what is where. If there isn't, I use google. If I'm sure that there isn't any ready to use solution, I implement it. If I hit a brick wall, THEN I ask. I simply don't get why people using VS still ask for things like "how to convert an integer to a string" (or vice versa). :doh:Greetings - Jacek
-
That happens to everyone. When I started with WinForms the first thing I did was write a nice class for linked lists. And then had my facepalm moment when I discovered the the System.Collections namespace :) To my defense: I used to work with C++ before and was used to be on my own for such things. Still, the class did its job and was a nice exercise to get used to managed references and garbage collection. And it gave me some impression about what kind of performance to expect from managed code.
At least artificial intelligence already is superior to natural stupidity
Heh, yep it does happen to everyone. In my first ASP.NET projects (quite a few years back), I used a lot of string concatenations (in for loops) and data binding to literals. After a couple of projects, though, I was introduced to (a) repeaters and (b) StringBuilders, and thought that they were the best thing since sliced bread (coming from a mostly PHP background, you can get how I felt when I was showed these aspects of the framework). Nowadays, I don't even dare to reopen those projects (and luckily most of them are already dead).
Φευ! Εδόμεθα υπό ρηννοσχήμων λύκων! (Alas! We're devoured by lamb-guised wolves!)
-
I'd like to call a hall of shame on myself - or, rather, my coding practices of about six years ago. Having just jumped into .NET, I was building a periodic table. I (manually) serialized the element data in a double-separated string (I think the separators were | for elements and ; for each of their attributes). The only problem was, I'd never heard of String.Split. I'd implemented a one-separator splitter once before using String.Substring, but the two-separator splitter was far more complex. About six hours of coding later, I had around thirty lines of String.Substring (if I still had the files, I would paste in the function). It worked, but looking back, I realize I could have replaced all that with a single line. Live and learn, I suppose.
Nearly Every time I open up a previous project I also enter myself into the Hall of Shame. It is natural, especially now days as the complications and convulsions are enormous. Today I opened up a project that is many years old and found an Access Database named tempory. It was supposed to be temporary. I could have claimed that it was a play on the Japanese word for fried battered vegetable and meat treats called tempura. It was for temporary issues of credentials, so a bit of a stretch. Spelling has often caused me embarrassment. Then again it is my right to call any DB or Table what ever I want to. And quite frankly the end user never sees this any way. We all learn and each project elevates us somewhat more out of the HOS. Then they invent a new Language and a new framework and we all have to re-learn all the stuff that we know backwards and dream about. It is an endless battle. But we all love it. :cool:
-
Nearly Every time I open up a previous project I also enter myself into the Hall of Shame. It is natural, especially now days as the complications and convulsions are enormous. Today I opened up a project that is many years old and found an Access Database named tempory. It was supposed to be temporary. I could have claimed that it was a play on the Japanese word for fried battered vegetable and meat treats called tempura. It was for temporary issues of credentials, so a bit of a stretch. Spelling has often caused me embarrassment. Then again it is my right to call any DB or Table what ever I want to. And quite frankly the end user never sees this any way. We all learn and each project elevates us somewhat more out of the HOS. Then they invent a new Language and a new framework and we all have to re-learn all the stuff that we know backwards and dream about. It is an endless battle. But we all love it. :cool:
Some misspellings are intentional and carried on like some kind of traditiuon. I always write 'Admon' instead of 'Admin'. In my project folder there even is a project with the name 'AdmonWebService' :)
At least artificial intelligence already is superior to natural stupidity
-
A lot of folk come to C# from some other language and they "already know how to program" so they don't look for how a task should be done. When starting with C# it is helpful to research how a task can be done with .NET rather than doing it the old C, C++ or Java way.
Just because the code works, it doesn't mean that it is good code.
On the one hand, it's good to continually look for ways to code elegantly in the place you find yourself. On the other hand, there's no shame in keeping it simple and programming in a way that is mutually recognizable across a number of languages. If the language-neutral version is hard to understand and you learn a better way in the language, just refactor it. Changing to something simpler and smaller is generally safer than the long slow trudge in the other direction that any code base tends to make over the years. :) I never saw much point in someone saying "I'm a C# developer" or "I'm a Java developer" or "I'm a C++ developer", like a single platform was a career or something. A successful career will outlive anything specific we know. The real deal is in a deep understanding of the patterns of design and usage that apply across platforms and being curious enough to learn what you would use to express them on several common ones and at least one emerging one.