|
I re-use a LOT of code. New projects simply get references to older assemblies.
My most often used are:
- "Common", which contains object extensions, connection string handling, attributes, and otherwise universally usable code
- "DAL", which contains database access code (that also references "Common"
- "WpfCommon", which contains controls, converters, a base class that supports INotifyPropertyChanged and IDataError, and my WPF wizard control stuff
As I go, I add things to those three, but since they've all been in my library for at least 10 years, they're pretty stable. Today, I added some extension methods for strings that allow me to perform ToUpper() and ToLower() on the specified part of a string, as well as a method that performs a Replace for all instances of a substring (like when you have an unknown number of consecutive spaces, and you want to reduce it to just a single space).
As far as starting a project from scratch, I have a MVC template I use that includes a lot of stuff I always do.As I add stuff to that list of things always done, I update the template. It includes all of the NuGet packages I use, and adjustments to the various files.
I created a "super" template for work that supports our app development techniques, and it starts you off with a complete running app with user reg/login, layout, and database support. The generated app includes documentation regarding how to code in the eco-system and where to find stuff. To make it app-specific, you only have to change one variable in Globals.asax.cs. The template already references the "Common" and the "DAL" assemblies, as well as app-specific BLL assemblies.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
No, really not. When you have stuff that is worth keeping, then give it its own project, maintain it there and add this project to any solution where it may be needed. This way you don't have redundant code floating around and don't accidentally import outdated stuff into a new project. And yes, it's peerfectly ok to maintain several such assemblies. You are not forced to marry things that don't belong together.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Depending on what I'm doing I always have a base starting point. If I'm making a mobile app, I have my base "mobile app" setup with a bunch of functions that I use all the time.
If I'm working on a PHP web project I always include my common PHP functions that I use a lot. These bases grow over the years and I"m constantly adding to them and sometimes removing stuff when the language i'm using adds new functions that solve stuff I had solved by making my own!
Good times. Starting from nothing is no fun.
|
|
|
|
|
This is a very good and interesting post.
I know you are an intelligent developer, so please understand what I'm saying is not about you not knowing this stuff.
It's incredibly interesting that there is so much copy/paste that goes on in this modern age and not near as much true re-use going on which is a huge part of OOP philosophy.
Again, I'm pointing this out not to indicate that you are not a smart dev, but that there are obviously some bits and pieces missing that don't allow re-use to be as easy as they should be.
The auth thing is terribly crazy to me that there isn't just a reusable pluggable component that everyone would be using.
|
|
|
|
|
raddevus wrote: The auth thing is terribly crazy to me that there isn't just a reusable pluggable component that everyone would be using. There is, but the URL's, client ID's, passwords, etc. are different each time.
So, copy paste and change those variables.
I always rename cookies, so:
services.Configure<CookieAuthenticationOptions>(AzureADDefaults.CookieScheme, options =>
{
options.Cookie.Name = "MyProject.AzureAdCookie";
}); Most stuff isn't worth putting in a library, like:
services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => Configuration.Bind("AzureAd", options)); But it gets copy pasted ALL the time
Perhaps a small library containing all that stuff..., but that's a library for four lines of code
MyUtils.ConfigureAzureAd("MyProject.AzureAdCookie"); Creating a NuGet repository is more trouble than it's worth though.
And if the code is customer specific you can't really have packages like "Sander.Utils" around either, they expect "Company.Utils" at the least, but so does that other customer.
So not even packages are always reusable
It's also a bit different for Azure Function projects, etc.
raddevus wrote: I know you are an intelligent developer
|
|
|
|
|
What you are describing is one of the things that I like about this job. Reusability! Every one of my new projects has bits and pieces of previous projects.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I do it twice. Stuff that I reuse more than that gets moved over to its own project for reusing. Plus, if I find a bug of sorts I can fix it in all projects in one go.
|
|
|
|
|
When I'm trying out something new sometimes I'll make a little test bench app to learn about it. That's a whole lot easier than adding it directly to one of our products and figuring things out there amidst three million lines of code.
Software Zen: delete this;
|
|
|
|
|
Message Closed
modified 12-Sep-19 8:07am.
|
|
|
|
|
Do you mean compile or actually test?
A function that adds a and a instead of a and b compiles fine, but it's still a bug.
I compile more often than test.
How often I compile depends on what I'm doing.
If I'm writing new functionality I usually don't compile until I think it's (partly) done.
Whenever I'm fixing bugs or typo's I sometimes compile after every few keystrokes.
And I save VERY often, like every minute or so (and sometimes more often).
|
|
|
|
|
Probably many of you already now it but just in case...
I was searching for an issue I am having with routed commands. I found a blog speaking about the article "Understanding Routed Events and Commands In WPF" by Brian Noyes and I just found:
MSDN Magazine Issues[^]
MSDN Magazine-Ausgaben[^] (Same site, German Version)
In there you might find a copy of all MSDN magazines to read online and or download for offline use. (Prior 2008 are in *.chm help files, which I actually find better as the PDF edition)
Thanks for it, Microsoft
(I only hope they don't deactivate the site after switching MSDN off)
EDIT: Just found another source (just in case): WebArchiveOrg : MSDN Magazine[^] (goes back to april 2008)
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 19-Sep-19 4:25am.
|
|
|
|
|
Nice, I started programming in August 2010.
The magazine for that month features an article about migrating to the Azure cloud, something I wouldn't be doing for another seven years or so.
The article is useless because everything changed.
There's an article on Windows Phone 7 (speaking of useless)
There's an article on Entity Framework by Julie Lerman, still with the old EDM file and the designer, something they've got rid of altogether with EF Core.
Something about Lazy<T> being cutting Edge (no, not the browser).
And something about NHibernate and Rhino Service Bus... Does anyone actually still use those?
Oh, how times have changed
|
|
|
|
|
Sander Rossel wrote: The article is useless because everything changed. There are probably going to be some of those cases... but still is a good collection.
And many other things are still relevant (or at least I hope so)
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Thanks! Bookmarked!
"Go forth into the source" - Neal Morse
|
|
|
|
|
You are welcome
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: (I only hope they don't deactivate the site after switching MSDN off)
Just download the PDFs...? The filenames all follow some pattern as I recall, so you could even script it.
Why people rely on links, especially on something that has had a history of changing so frequently as those from MS, instead of downloading stuff when it's an available option...I'll never understand.
|
|
|
|
|
I am going to download it, but the pattern is not that easy.
Code samples are named correctly, the rest have cryptic names not that correlated as I would like.
If I have to do it manually... it will take a time, but I will do it too
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I just had a look, and it seems like you're correct - it's definitely not the simple "https://...xxxxxxxxxxxMMYY.pdf" pattern I thought I remembered. Even scraping the page for links to .PDF files might not be that easy. Sorry about that.
I've been getting them one-by-one as they've been coming out for years now, so I never had a big queue to catch up with.
I'd be happy to zip up and share my collection as a single file [*], but my upload bandwidth is well under 1mbps, flakey as hell, and tends not to resume interrupted downloads all that well (or uploads in this case).
The only single-file download I can find right now is the old 2000-2002 archive, at archive.org, but clearly this isn't what you want...I have little doubt someone somewhere might have the whole collection available through a one-click download - these are the sorts of things people tend to make available that way.
[*] They're free downloads, I'm sure the copyright police at MS would look the other way for something like this...?
|
|
|
|
|
Very nice from you, but don't worry...
Ken told below, that they are moving the whole content to the "Docs" area.
If I get dead times in from of the computer, I will start downloading on my rhythm. Thank you anyways for the offer.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nice! Thanks for sharing that.
Software Zen: delete this;
|
|
|
|
|
You are welcome
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: (I only hope they don't deactivate the site after switching MSDN off)
No, it will be migrated over to Docs, along with all the magazine content.
TTFN - Kent
|
|
|
|
|
Nice.
Thanks for the information.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Old Leny swear a reveal for nervous keeper. (6, 7)
|
|
|
|
|
Ronald Weasley
Anagrams do make it easier...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|