Subj : Re: Eclipse (was Re: Visu
To   : Mercyful Fate
From : Khelair
Date : Sun May 10 2015 07:50:00

  Re: Re: Eclipse (was Re: Visual Studio 2013 settings regarding indentation
  By: Mercyful Fate to Khelair on Sat May 09 2015 03:24:27

 MF> Cool, if you find something worth wide, post it about here and we'll check
 MF> it out :)

  Well right now I'm checking out Komodo.  I've only just installed it, so I
haven't gotten deep with it yet...  Only problem that is really frustrating me
right now is the fact that I can't run it natively on my BSD machine, which is
where I've got the BBS and like to do development for my shell.  Something
tells me that unless it's _really_ good, I'm not going to be dealing with
'scp'ing those file contents over and over again every time to test out the
changes that I've made...  That's only my first attempt, though.  I've got a
few other alternatives in the queue.  Hopefully something that will run on BSD
or a good web app will pop up soon here.  I figured I'd start looking at native
environments, first, though, for the same reasons as mentioned before..

 MF> Hope you like it, i learned alot from it with initial testing and good
 MF> ways to go about writting tests.

  I haven't checked it out yet, but I'm going to very soon here.  I _know_ that
TDD or unit testing would make my life so much easier in coding; actually I'm
having a rough time getting started this morning, I'll probably check it out
after I send this message here.  Maybe it'll help me bootstrap into some better
productivity.

 MF> I started using some of the pratices on my new code, and it helps to break
 MF> to down and test every scenario that you throw at it, then you know it's
 MF> solid, and if you have to change something lateron on, you just run the
 MF> test and make sure you didn't break anything.  The only down side is
 MF> writting tests can be slower in the begining, but it saves alot of time
 MF> lateron when you trying to hunt bugs down and it also documents hows each
 MF> class is suppose to function.  So walking away you can come back and easy
 MF> see, of year this method only handles parameters or ranges in this way.
 MF> Then you can either extend it if needed or write something new.

  Yep.  I don't mind things going slower at the cost of maintainability and
extendability, though.  I can easily see those advantages weighing the favor at
this point.

 MF> I look back and i see some really bug functions with lots of case
 MF> statements and loops and i'm like shit i really need to break this down
 MF> becasue when something isn't working, tracing through a big mess like that
 MF> just isn't going to work.  Then when it comes to trying to rewrite it. i
 MF> just makes my head hurt.. haha

  Yep.  I've got quite a few stretches of horror-spaghetti code in my work
right now.  A few months back I went on an editing and refactoring binge in my
code and tried to break everything like that down into bits that I could
maintain better.  Unfortunately there are a few more monoliths that have come
into being in my code again since then...  Not to mention a ton of debugging
cruft because I'm not handling things in a better (testing?) fashion, as well.
  Anyhoo, I'm gonna go check out that video.  :)  Gotta kick myself in the butt
on this again somehow, por dios.

  -D/K

---
Borg Burgers:  We do it our way; your way is irrelevant.
 þ Synchronet þ Tinfoil Tetrahedron BBS telnet://tinfoil.synchro.net

.