• Advertisement
Sign in to follow this  

Using a Notepad in Industry to keep track of modified code

This topic is 1528 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is that common to have a programmer have a notepad in front of him/her keep track of code that was modified (ie: list before and after code comparison, line location from the IDE)?

 

I figure if someone modifies something, there might be a chance something else might break in a different area of the program. So this would be a good way to revert the issue.

 

I never worked in the industry. I am still a CS undergraduate but I was curious about whether or not this is actually how it works in industry.

Share this post


Link to post
Share on other sites
Advertisement

Yeah use software to track changes (also called source control). I'm surprised they don't teach you about that in uni. SVN and SourceSafe are 2 I have used in the past (Git has been mentioned too, not used it).

 

I'm a firm believer in notepads though, notepads don't crash and lose your data. Best notepads are hardbound and you can't rip pages out. Always keep your old notepads. It's also best to date each entry. (Not "sexy time" date, calendar date).

 

EDIT: Biggest problem with notepads is illegible writing ;)

Edited by Paradigm Shifter

Share this post


Link to post
Share on other sites


Personally, I use git for my code these days... but I'd probably recommend Subversion (and TortoiseSVN for integration with Windows Explorer) as it's easier to learn.

I don't want to take us too far off topic, but I'd go exactly the other direction on this.

 

SVN is full of odd little pitfalls that only occur in weird edge-cases, whereas git has a very simple set of base operations which tend to be self-consistent. Yes, advanced operations are unintuitive in both, but SVN is hair raising...

Share this post


Link to post
Share on other sites

There's a whole set of software tools known as version control (or "revision control") which solve this problem far more powerfully than doing it by hand.

Interesting.

Share this post


Link to post
Share on other sites

Yeah use software to track changes (also called source control). I'm surprised they don't teach you about that in uni. SVN and SourceSafe are 2 I have used in the past (Git has been mentioned too, not used it).

 

I'm a firm believer in notepads though, notepads don't crash and lose your data. Best notepads are hardbound and you can't rip pages out. Always keep your old notepads. It's also best to date each entry. (Not "sexy time" date, calendar date).

 

EDIT: Biggest problem with notepads is illegible writing ;)

What course do they teach about source control? I'm a CS undergraduate and I am taking 2 CS Classes this semester: Computer Architecture and Discrete Structures.

Share this post


Link to post
Share on other sites

 

Yeah use software to track changes (also called source control). I'm surprised they don't teach you about that in uni. SVN and SourceSafe are 2 I have used in the past (Git has been mentioned too, not used it).

 

I'm a firm believer in notepads though, notepads don't crash and lose your data. Best notepads are hardbound and you can't rip pages out. Always keep your old notepads. It's also best to date each entry. (Not "sexy time" date, calendar date).

 

EDIT: Biggest problem with notepads is illegible writing ;)

What course do they teach about source control? I'm a CS undergraduate and I am taking 2 CS Classes this semester: Computer Architecture and Discrete Structures.

 

there are usually no courses directly related to source control, however it will often be used in larger practical excercises.

 

In any case, beside git and svn you could also check out (vcs pun, yay!) perforce, which is quite commonly used in industry and free for up to 20(?) users.

Share this post


Link to post
Share on other sites

As a solo programmer, I've found git far more useful than svn. Once you understand how it works, it's extremely easy to set up, branch off modifications, compare those changes, and merge them together. I would never dream of doing this by hand.

Share this post


Link to post
Share on other sites
What about Mercurial?

 

...And it begins.

 

Git vs. Mercurial: Please Relax (Git is MacGyver and Mercurial is James Bond)

The Differences Between Mercurial and Git

Git is Wesley Snipes, Mercurial is Denzel Washington

 

My honest opinion on Mercurial: To me it feels like Mercurial is just unnecessary. It does everything git does, only slower, and it's missing a few features. Plus the name "Mercurial" is unfortunate. Not catchy and doesn't "feel" good. That's just my opinion. I'm not denying Mercurial is a good VCS; quite the contrary, it does what it's designed to do and it does it well.

 

If you tell me to use Mercurial over Git, though, the reason I wouldn't switch is not because I prefer git, but because the time it would take to learn how to use Mercurial would outweigh the supposed benefit you claim it has.

 

I'll quote the first article. The bottom line is:

 

  1. Evaluate your workflow and decide which tool suits you best.
  2. Learn how to use your chosen tool as well as you possibly can.
  3. Help newbies to make the transition.
  4. Shut up about the tools you use and write some code.

 

 

Edited by TheComet

Share this post


Link to post
Share on other sites

Mercurial is not slow. I switched from Mercurial (also called hg if you find that more catchy) to using git, but only because there are a few corner cases where it is more flexible. The downside is git got obscure commands you need to type in with ambiguities, 2 commands for same thing and 1 command doing 3 things.

hg you can learn in a day with easy commands you can even shorten when you type them in and rarely needs extra switches. Command names also have similar meaning as in SVN if you switch from it. Turtoise hg is also nice, I think they programmed it from scratch for hg only using the pictures of Turtoise SVN.

git you need to study and google for commands and dozens of switches per command for years to come. If you used SVN first, google every command, because all got intentionally renamed and do something else if you type in the original command. Turtoise git you better not use, I think that got into live as an awkward mutation of Turtoise SVN and did not fit git well.

 

The good thing of both compared to SVN is you can easily setup a repository, have everything locally on your computer without needing constant access to a server, you can easily setup a repository on an USB stick and push from your HDD to it to have a local backup in case the HDD or the server blows up and merging (and you can additionally rebase) is so much easier.

Edited by wintertime

Share this post


Link to post
Share on other sites

From my college experience, maybe one or two professors touched on source control for a total of five minutes. There wasn’t a specific class for it nor was it mandated in any class to be used (or encouraged to be used at all really). It was one of those things that I learned on my own and used on my own, and mandated for the team projects that I was a part of.

 

As far as I can tell, that’s more or less the common story. You wouldn’t believe how often we get soon-to-be-new graduates coming in for interviews and they only have “vaguely” heard of source control.

 

As for notepads, I like those big yellow legal pads myself. Always have a stack of them in my drawer, and always one open beside me while working. Very useful for notes during debugging or sketching out new ideas or designs. That may range from literally diagramming something in 2D or fleshing out an algorithm in pseudo code. It’s a good habit in my opinion.

Edited by Starnick

Share this post


Link to post
Share on other sites

Yes, I do it all the time.  Perforce or Git don't really track that or the relationships between different files or calls.  It's easy to forget or have a hard time finding what you're looking for in perforce because it can be hard to forsee future needs.

 

I also write general notes on the files I'm working on or of interest to me, function and line numbers I'm interested in, reminders, TODO lists, math, call graphs, etc.

 

In general if you find a habit of yours is proving useful, keep doing it :)

Share this post


Link to post
Share on other sites

Yeah, I sometimes do write down basic class/function relations on paper, too. But often its changing fast and you could never write down all of it even for a single time.

I wish there was a tool you could feed a whole source tree in, which would then automagically generate a nice, easily customizable diagram of all classes, member and global variables, methods, functions, including different lines for inheritance, calls and bad use of public variable read/write. That is, it should go exactly backwards from the commonly told way of sinking much time into creating an UML diagram (which seem to get too coarse grained to be useful and dont include methods), then implementing it, then some changes get made and the diagram is useless.

What I saw from doxygen class diagrams feels not really useful enough to me, because I can just look at 1 to 3 header files and see the same.

Share this post


Link to post
Share on other sites

AFAIK, warnexus is using Java. So, based from that...

 

Eclipse has plugins for handling version control for git (EGit), Mercurial (MercurialEclipse), and so on (Subversion, CVS, etc).

 

The things you need is a: A repository (it can be local but preferably in some website, BitBucket supports Git and Mercurial, GitHub supports Git only I think), and b: The plugin. Once you have both, you can follow some tutorial to set up your repository.

 

I use Mercurial, started to use it because I wanted to have my code somewhere so I don't have to copy it back and forth between my desktop/netbook. That's a big plus, besides that you get the opportunity of commenting each commit individually, having the whole history of each file you modify, and watching your progress in a handy commit history page :)

Share this post


Link to post
Share on other sites

AFAIK, warnexus is using Java. So, based from that...

 

Eclipse has plugins for handling version control for git (EGit), Mercurial (MercurialEclipse), and so on (Subversion, CVS, etc).

 

The things you need is a: A repository (it can be local but preferably in some website, BitBucket supports Git and Mercurial, GitHub supports Git only I think), and b: The plugin. Once you have both, you can follow some tutorial to set up your repository.

 

I use Mercurial, started to use it because I wanted to have my code somewhere so I don't have to copy it back and forth between my desktop/netbook. That's a big plus, besides that you get the opportunity of commenting each commit individually, having the whole history of each file you modify, and watching your progress in a handy commit history page smile.png

Thanks for the info! rolleyes.gif Thumbs up!

Share this post


Link to post
Share on other sites
What course do they teach about source control?

Unfortunately many college and university courses still completely skip any lessons on important tools such as source control (for tracking changes to code as discussed in this topic), profilers (for tracking down performance issues) and debuggers (for diagnosing and fixing problems with code) or only really cover it in passing during course-work rather than formally teaching it, so there's unfortunately a good chance that you simply won't be taught about any of these things in your course.

 

I'd strongly recommend taking some time to teach yourself the basics of all of these tools to see how they can fit into and improve your development process.  Most people learn about all of these things once they're employed, but you might give yourself a leg-up in getting hired if you can learn about these things by yourself beforehand, and you'll likely find you can improve your workflow in your personal projects as well; in particular, you can save yourself a lot of time and effort by learning to properly use a debugger.

Share this post


Link to post
Share on other sites


I'd strongly recommend taking some time to teach yourself the basics of all of these tools to see how they can fit into and improve your development process. Most people learn about all of these things once they're employed, but you might give yourself a leg-up in getting hired if you can learn about these things by yourself beforehand, and you'll likely find you can improve your workflow in your personal projects as well; in particular, you can save yourself a lot of time and effort by learning to properly use a debugger.

 

Nice points!

Share this post


Link to post
Share on other sites


but you might give yourself a leg-up in getting hired if you can learn about these things by yourself beforehand

Depending on where you want to be hired, it may not make any difference.

 

The "big 10" companies seem to focus a lot more on straight CS: recursion, algorithms, data structures, object-oriented design. Things like build systems and source control vary immensely by company and team, so they expect a fairly significant ramp-up time anyway.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement