Author Topic: Same Code, Multiple Projects, Multiple Builds  (Read 18296 times)

0 Members and 1 Guest are viewing this topic.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #45 on: October 30, 2015, 10:19:14 AM »
Found on MSDN for what it's worth: Project Linker: Synchronization Tool
...
And here is something to consider for your tool CadBloke if you keep at yours:
Quote
An option to synchronize projects?
4 Posts | Last post June 11, 2013

Written March 07, 2013
Miha Markic
AFAIK there isn't an option to re-link the projects if they get unsynchronized - i.e. if I edit only the source project without the target.
...

Written June 11, 2013
Jonkers
Published the project at https://projectlinker2012.codeplex.com

My project keeps the targets refreshed already. If you use a post-build event then it happens every time you build the source. The target doesn't need to be loaded anywhere, it just need to be accessible to the file system.

I'll have a look at that repo at CodePlex when I get the chance. I had a quick look at the MSDN page. I think checking for duplicates is a good idea, I'll get on to that ... sometime.

If you haven't pulled from the Github repo in the last couple of days then you may notice it changed. I got sick of fiddling with sanitised histories to I reset the Github repo to be the same as my work in progress. Same code, more rants. I'm leaving it there in that form. I have also updated the Wiki.

I didn't want anything as intrusive as VS extension or something that has to be installed and/or live in the PATH. I wanted Code Linker to be as portable as the source code - it will work for anyone who clones the repo as long as CodeLinker.exe is in the repo. It has no dependencies, it doesn't even depend on Visual Studio.

As it stands I am using this already and it is working well for me. It actually builds itself, 3 of the 4 projects in that repo are built from the original command line project.

That's the way your repo should be! You are writing this so you (or someone else) can come back and figure out where bug 'x' was introduced and "why" you choose to do something. ...a sterile history does anyone very little good at all; Use tags and releases. Don't worry about your history as much as you do. This is a process not a leap.

I did clone your project and started looking at it. One suggestion is to start cleaning your code a little (and where are the comments!!). Your syntax rules are all over the place; pick a std syntax rule and stick to it.
For example:

Bad:

Code - C#: [Select]
  1. if (test) code

or

Code - C#: [Select]
  1. if(test)
  2.     code
  3. // These look nice but are hard to read later (when looking for bugs you are scanning the code and
  4. // this style gets in the way often.


Good:
Code - C#: [Select]
  1. if ( test ) {
  2.     code
  3. }
  4. // My rules:
  5. // 1. Space before the '('.
  6. // 2. Space before <TEST>.
  7. // 3. Open '{' on same line.
  8.  
  9. if ( test ) {
  10.     code
  11. } else {
  12.     more code
  13. }
  14. // Else on same line as '}'

or

Code - C#: [Select]
  1. if ( test ) {
  2.     code
  3. }
  4. else {
  5.     more code
  6. }
  7. // Else on new line.

My rules are evolving over time but I normaly put the '{' on the same line of everything (functions, statements, etc) except CLASSES and NAMESPACES.

NOTE:
Code - C#: [Select]
  1. internal string SOMETHING { get; ]
is okay.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

CADbloke

  • Bull Frog
  • Posts: 334
  • Crash Test Dummy
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #46 on: October 31, 2015, 04:37:39 AM »
If you haven't pulled from the Github repo in the last couple of days then you may notice it changed. I got sick of fiddling with sanitised histories to I reset the Github repo to be the same as my work in progress. Same code, more rants. I'm leaving it there in that form. I have also updated the Wiki.
That's the way your repo should be! You are writing this so you (or someone else) can come back and figure out where bug 'x' was introduced and "why" you choose to do something. ...a sterile history does anyone very little good at all; Use tags and releases. Don't worry about your history as much as you do. This is a process not a leap.
My own history always had all this, I'm a prolific committer and will often break commits up just to separate the bits I brokefixed. I guess I was worried about people looking at the commit log and dimissing me as insane. Meh, they were bound to figure that out sooner or later anyway.

As an aside, Git in Visual Studio 2015 Professional with CodeLens is cool, you can go straight to the relevant commits for the code you are looking at.

...as well as navigating a list of the usages of the item too. Bummer it's not in the Community edition.

One suggestion is to start cleaning your code a little (and where are the comments!!). Your syntax rules are all over the place; pick a std syntax rule and stick to it.
...
My rules are evolving over time...
Yeah, that project was also an experiment in what formatting rules would work for me... so I tried them all. I just added at 27 inch 2560x1440 monitor to my desktop so that hasn't helped with any notion of clever use of space. I also did a lot of this at night, after a long day's work and after putting 2 kids to bed. Nevertheless, it's a mess and it needs fixing.

I also have quite colourful syntax highlighting in Visual Studio ...

...so visually separating types of things is easy for me. Yes, it looks like http://www.frootloops.com/ and some of you probably just threw up a little but nyah, it works for me.

Regarding braces and where to put them, there's always going to be differences in opinion and hot debate on that one, see http://programmers.stackexchange.com/questions/2715/should-curly-braces-appear-on-their-own-line#

Personally I prefer them on their own line, I like the visual separation.

I do agree that all the bits where I left off the braces need them back, lest I make another goto fail. That's just plain wrong.

I use Resharper and it has such a complex matrix of formatting rules that they often disagree with each other and leave you wondering why it moved things around like it did. I need to sort those rules out and ctrl-A-E-C all the things. As you said...I need to pick a std syntax rule and stick to it. Just looking at that pic I posted there are at least 3 different formats for "if". Wow, was I drinking? Yeah, that's not right. I will definitely fix that before moving on. I'll even use the same repo this time! (not deleting the Github repo again unless I drop a credit card in it).

Comments? There's another hot debate.  I try to name things so obviously and verbosely that they are their own comments. *Try*. Or do you mean more XML doc comments? Please let me know where you think comments would help, I'm interested to know what I may be missing.

BTW, the Visual Studio Gallery is indeed the place to go for plugins. I use a few and yes, they slow things down a little (especially Resharper) but they help more than they hinder. If you look at the screengrab you may notice the brackets and braces are different colours - they actually use the resistor colour code so I can easily tell where they match and how deep they are nested. Trivial but I find it useful.

I updated the pics at http://www.theswamp.org/index.php?topic=50202.msg553839#msg553839 and also the wiki article at https://github.com/CADbloke/CodeLinker/wiki/Illustrated-Example with new screenshots.

I have some broadcast system design work that needs doing over the weekend so I won't be able to get onto this for a few days. Broadcast systems are my day job, rest assured I'm better at that than I am at this.

In the meantime I set myself a reminder
« Last Edit: October 31, 2015, 08:07:41 AM by CADbloke »

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #47 on: November 02, 2015, 10:58:42 AM »
...
Yeah, that project was also an experiment in what formatting rules would work for me... so I tried them all. I just added at 27 inch 2560x1440 monitor to my desktop so that hasn't helped with any notion of clever use of space. I also did a lot of this at night, after a long day's work and after putting 2 kids to bed. Nevertheless, it's a mess and it needs fixing.
...

Stick to the 80 character width (or close to it) until you nail down a style.


...
Regarding braces and where to put them, there's always going to be differences in opinion and hot debate on that one, see http://programmers.stackexchange.com/questions/2715/should-curly-braces-appear-on-their-own-line#

Personally I prefer them on their own line, I like the visual separation.

I do agree that all the bits where I left off the braces need them back, lest I make another goto fail. That's just plain wrong.

I use Resharper and it has such a complex matrix of formatting rules that they often disagree with each other and leave you wondering why it moved things around like it did. I need to sort those rules out and ctrl-A-E-C all the things. As you said...I need to pick a std syntax rule and stick to it. Just looking at that pic I posted there are at least 3 different formats for "if". Wow, was I drinking? Yeah, that's not right. I will definitely fix that before moving on. I'll even use the same repo this time! (not deleting the Github repo again unless I drop a credit card in it).
...

It's fine to have an opinion and even better to read up on those but I wanted to talk about the braces thing a second because the braces on the same line offers you a feature you (or the "discussion" on SO you liked to) probably haven't addressed/thought of; Searches. To give you a solid example: if you do a search (with Visual Studio or Grep) for the string "DestinationProjLinker". You'll get this line:
" ...  \CodeLinker\DestinationProjLinker.cs(13):    internal class DestinationProjLinker"

If you had a brace on that line you'd be able to quickly discern which instance in that list is the definition code and jump there. This is, of course, a very simple example, but the principle becomes a huge time saver in a large project.

If I were you, I'd ditch reshaper until you can formulate your own opinions about what you want to look like.


...
Comments? There's another hot debate.  I try to name things so obviously and verbosely that they are their own comments. *Try*. Or do you mean more XML doc comments? Please let me know where you think comments would help, I'm interested to know what I may be missing.
...

I wont even click on that link; I've read that debate a 1,000 times and I don't care. I comment my code <period>. I can use simple command line tools to remove them if I had too.

The point I am trying to make is simple, try not to be so dead fast on one solution. It's great to read and find out what other people are doing but you'd be far better off reading a coding standard (Google, Mozilla, LLVM/CLANG, Chrome, etc) then to read those threads loaded with out of context opinions.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #48 on: November 03, 2015, 10:14:09 AM »
I got a moment to start looking through your code. Now, please bear in mind that I am an absolute beginner with Csharp so I am not a resource on syntax and api stuff.

I started in "Program.cs" and I noticed that you just pass the argument list to the "App" class and parse the args from there. This isn't "terrible" (I would have, however, skipped the "app" class all together and added those functions [Parse commands, Crash, & Finish] to the main class but I digress to my point). Your argument handling is a big/nasty If-Else-If chain. So, my first code related comment will be to hopefully give you something useful. This, hopefully, is a crude argument handler which you can expand for simple arguments like you require.

Code - C#: [Select]
  1. for (int x = 0; x < args.Length; ++x) {
  2.     // Parse the argument list.
  3.     //
  4.     //      /?  :       Call help, Write log, Finsh the app.
  5.     //      /s  :       "I don't have a clue as to what this is
  6.     //                   I just put this in here for example." -7
  7.     //      ...
  8.     if (args[x] != "" && args[x].Length > 1) {
  9.         if (args[x][0] == '/' && args[x][1] == '?') { Help.Write(); Log.WriteLine("User asked for help."); Finish(); }
  10.         if (args[x][0] == '/' && args[x][1] == 's') { doSubDirectories = StringComparer.CurrentCultureIgnoreCase; }
  11.     }
  12. }
Use this to populate variables and call simple functions from. This is NOT meant to be a "main loop" of your program; it is only meant to set up.
« Last Edit: November 03, 2015, 10:29:01 AM by John Kaul (Se7en) »
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #49 on: November 03, 2015, 02:37:22 PM »
Looks like someone ported the GNU getopt() function to .net. Instead of using my suggestion you can also use this in your project to clean the argument processing up.

http://getopt.codeplex.com/
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

CADbloke

  • Bull Frog
  • Posts: 334
  • Crash Test Dummy
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #50 on: November 03, 2015, 06:43:29 PM »
I started in "Program.cs" and I noticed that you just pass the argument list to the "App" class and parse the args from there. This isn't "terrible" (I would have, however, skipped the "app" class all together and added those functions [Parse commands, Crash, & Finish] to the main class but I digress to my point).
Necessary because there are two Program.Main()s, one for the command line project and one for the GUI project. Both projects use the App class.

Your argument handling is a big/nasty If-Else-If chain.
Looks like someone ported the GNU getopt() function to .net. Instead of using my suggestion you can also use this in your project to clean the argument processing up.

http://getopt.codeplex.com/
Crude, ugly but it works, it deals with all the decision paths, it doesn't have a dependency on an external library so anyone who knows what if...else does can already parse it and maintain it. It grew from just a couple of decision paths to what it is now. If I thought it was going to grow any larger then I'd refactor it into something a little more elegant like a big, nasty switch...case chain which is what Getopt wants you to do anyway. From http://getopt.codeplex.com/SourceControl/latest#Gnu.Getopt/Gnu.Getopt/Getopt.cs ...

Code - C#: [Select]
  1. /// Here is a basic example of using Getopt:
  2. /// <code>
  3. /// Getopt g = new Getopt("testprog", args, "ab:c::d");
  4. ///    
  5. ///     int c;
  6. ///     string arg;
  7. ///     while ((c = g.getopt()) != -1)
  8. ///     {
  9. ///             switch(c)
  10. ///             {
  11. ///                     case 'a':
  12. ///                     case 'd':
  13. ///                             Console.WriteLine("You picked " + (char)c );
  14. ///                             break;
  15. ///                                    
  16. ///                     case 'b':
  17. ///                     case 'c':
  18. ///                             arg = g.Optarg;
  19. ///                             Console.WriteLine("You picked " + (char)c +
  20. ///                                     " with an argument of " +
  21. ///                                     ((arg != null) ? arg : "null") );
  22. ///                             break;
  23. ///    
  24. ///                     case '?':
  25. ///                             break; // getopt() already printed an error
  26. ///    
  27. ///                     default:
  28. ///                             Console.WriteLine("getopt() returned " + c);
  29. ///                             break;
  30. ///             }
  31. ///     }
  32. /// </code>

Using a library like that just means everybody has to learn it and then I have to rewrite it to make it do what it already does without breaking it. If you'd like to do that then go right ahead. I'm ok with "ugly but it works".

Yes, I think a few comments would help. You can always run it with "/?" and read the help text in the log to see what the switches do.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #51 on: November 03, 2015, 06:52:48 PM »
You have the dumbest excuses!  Getopt isn't some enigma...its been around since the 80's!!
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

CADbloke

  • Bull Frog
  • Posts: 334
  • Crash Test Dummy
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #52 on: November 03, 2015, 08:01:48 PM »
I think I've had enough of the snark.
http://tirania.org/blog/archive/2010/Dec-31.html
Thank you for your help, we're done.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #53 on: November 03, 2015, 10:03:16 PM »
Yes, I know (your last post was about as much as I could take).

I don't think any of my recommendations were out of line at all (I've asked you to conform to any *one* style of *your* choosing). And yes, I got real sick and tired of making suggestion after suggestion only to be shot down for the oddest reasons. I'm sorry you think the suggestions I made (use git instead of a manual method third party tool, remove unreliable If-Else-If chain, use or don't use braces for IF statements, etc) are bad etiquette. If you are not looking for suggestions/review/ideas I am a little confused as to what this thread is for (what is this threads purpose).

FWIW, I had some fun. Good luck.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

CADbloke

  • Bull Frog
  • Posts: 334
  • Crash Test Dummy
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #54 on: November 03, 2015, 10:13:02 PM »
Having a (opposite of "fun") day so I'm in no mood to hear "ugly" and "dumbest" directed at something I hand-made and put out there for everyone to have. Perhaps I should avoid humans until the thickness returns to my skin.

FWIW your suggestions have a lot of value to me and to the lurkers too, I'm sure. I've learned heaps. Sorry if you think I was shooting you down, I was just trying to explain myself. The tone just got me down in the end.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #55 on: November 03, 2015, 10:26:21 PM »
You used ugly not me. And what should I call it when someone says they think a method that has been ported to many languages and is used in thousands of programs is worse then a fragile if-else-if chain?

I think you should keep going but do not hesitate to refactor when you should.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

CADbloke

  • Bull Frog
  • Posts: 334
  • Crash Test Dummy
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #56 on: February 22, 2016, 06:19:44 AM »
I added fixed some more bugs and things if anyone is actually using this .. or wondering just how bad my code can get .. https://github.com/CADbloke/CodeLinker/commits/master and my excuses explanations at https://github.com/CADbloke/CodeLinker/issues?q=is%3Aissue+is%3Aclosed

Updated the Wiki page on using the GUI app - it's mostly draggy-droppy, like all good programming.

You wouldn't believe how drunk I had to get to write Lines 111 - 117.   :whistling:
« Last Edit: February 22, 2016, 07:12:19 AM by CADbloke »

CADbloke

  • Bull Frog
  • Posts: 334
  • Crash Test Dummy
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #57 on: March 02, 2016, 09:19:33 PM »
Stumbled over yet another command line parser that looks ok: https://github.com/dotnet/corefxlab/tree/master/src/System.CommandLine

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9778
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #58 on: March 04, 2016, 09:53:19 AM »
Looks big and complicated. What was wrong, again, with the getopt() method I linked to or the hand-rolled--very simple--version I made for you? ...why add unnecessary complexity to a very simple task (more lines of code does not equal better)?
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

CADbloke

  • Bull Frog
  • Posts: 334
  • Crash Test Dummy
Re: Same Code, Multiple Projects, Multiple Builds
« Reply #59 on: March 07, 2016, 07:48:44 AM »
Looks big and complicated. What was wrong, again, with the getopt() method I linked to or the hand-rolled--very simple--version I made for you? ...why add unnecessary complexity to a very simple task (more lines of code does not equal better)?
I didn't have a close look at that, just adding it for anyone following along, for future reference.

(more lines of code does not equal better)?
Totally agree, it makes it worse - more lines == more bugs.

Back to the original topic ... I tweaked a few more things and also Resharpered the whole thing. I even set the indents to 4 instead of 2 ... which was really dumb and is not going to be much fun when I fix bigger codebases.#fail