TFS annotate?
On 13 Sep 2013 14:47, wrote:
> Anyone suggest a method to autmaticlly comment code when lines have
> changed? Would be great to be able to see who changed what when viewing
> the code.
>
> ** **
>
> At the moment,, we write comments like //xxMOD 12AUG13 XX=PROGRAMMER
> INITIA
A lot of source control systems give you that out of the box. I know Git
and SVN both do with the BLAME command. I wouldn't want the comments
scattered throughout the code.
On Fri, Sep 13, 2013 at 2:45 PM, wrote:
> Anyone suggest a method to autmaticlly comment code when lines have
> changed?
...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Craig van Nieuwkerk
Sent: Friday, 13 September 2013 2:50 PM
To: ozDotNet
Subject: Re: Code commenting
A lot of source control systems give you that out of the box. I know Git and
SVN both do with the BLAME command. I wouldn't wan
**
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Craig van Nieuwkerk
> *Sent:* Friday, 13 September 2013 2:50 PM
> *To:* ozDotNet
> *Subject:* Re: Code commenting
>
> ** **
>
> A lot of source control systems gi
Annotate is the 'glass is half full' name for blame in TFS.
On 13 Sep 2013 14:50, "Craig van Nieuwkerk" wrote:
> A lot of source control systems give you that out of the box. I know Git
> and SVN both do with the BLAME command. I wouldn't want the comments
> scattered throughout the code.
>
>
> O
--
>>
>>
>> ** **
>>
>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
>> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Craig van Nieuwkerk
>> *Sent:* Friday, 13 September 2013 2:50 PM
>> *To:* ozDotNet
>> *Subject:* R
Blame is a useful tool, ofttimes though, I'd call it credit. For instance,
you receive a crashdump from an old version, it shows you where the app
crashed, and maybe you have a slight idea why. Use blame on a current
version, look at changes around the crash line and you've got a lot of the
info
Hello
If you are doing this in code. It points to the fact that someone is not
pulling their weight.
Code should not have comments. If you need them to explain something, the
code is too complex.
If you add them so modifications on one bit of code come back to you so you
can fix. Make it simpler.
I
No comments at all is a bit extreme. I get what you're saying, but there
are still valid reasons for comments. For example, if you had to do an
unusual hack because of a bug in the framework, you'd want to leave a
comment in the code so the next person who comes along doesn't spend hours
re-writing
For the last 5 years or so the only comments that I have left in code. are
the public interface XML comments that are well written with examples. not
the usual you find.
///
/// Gets the User by Id
///
public void GetUserById(long id){}
I have left comments that point out that a bug exists in so
If it was hard to write it should be hard to read :)
Why comment?
On Fri, Sep 13, 2013 at 5:56 PM, Davy Jones wrote:
> Hello
> If you are doing this in code. It points to the fact that someone is not
> pulling their weight.
> Code should not have comments. If you need them to explain something,
Just run it thru an obfuscator before committing it
On Mon, Sep 16, 2013 at 9:46 AM, Corneliu I. Tusnea
wrote:
> If it was hard to write it should be hard to read :)
> Why comment?
>
>
> On Fri, Sep 13, 2013 at 5:56 PM, Davy Jones wrote:
>
>> Hello
>> If you are doing this in code. It points to
Corneliu IS an obfuscator.
;)
On Mon, Sep 16, 2013 at 8:58 AM, mike smith wrote:
> Just run it thru an obfuscator before committing it
>
>
>
> On Mon, Sep 16, 2013 at 9:46 AM, Corneliu I. Tusnea <
> corne...@acorns.com.au> wrote:
>
>> If it was hard to write it should be hard to read :)
>> Why
13 matches
Mail list logo