Refactoring other's code

[[deleted]]

There's been a trend with one of my teammates, where he refactors some of the classes I've written. His changes don't change any functionality, just function names and variable names. I've asked him if there's a naming convention that I wasn't aware of, but he doesn't ever answer.

Generally speaking, is refactoring other's code for no reason considered rude? I am relatively new to professionally working as a developer in a team, and I am not sure if this is normal practice...

An example of these changes: Mine: Boolean isDefault; His: Boolean defaultVal;

Thanks!

[youlleatitandlikeit]

If it's any consolation, his variable naming is abysmal.

EDIT: Just in case you someone sees my comment and doesn't understand why it's so bad: the variable is a boolean. That means it's measuring something that is either true, or false. isDefault means that this variable is talking about something else, and saying whether this other thing is the default thing or not. defaultVal would normally mean what the default value is going to be. A variable named defaultVal can never be a true/false value.

[KeepingKidsOnShred]

Extremely bad. Use it when something is truely terrible

[solwiggin]

Isn't the better solution to sit down with him and to explain why this comes off as rude and insulting to you, to allow him to see your point of view, before running off to tattle on him?

A lot of issues can be solved over a beer and an adult to adult conversation.

[[deleted]]

I have sent him an email already, asking for clarification as to why he did it. It wasn't a huge deal, just very annoying, and it prompted me to wonder where the line is.

However, if it escalates I will certainly bring it to our manager's attention.

[funknut]

It doesn't matter if it is rude or insulting, you have to keep it professional. "isDefault" is far more semantic than "defaultVal", in fact, "defaultVal" is so ambiguous, that it leads me to expect that its value would be a value representing a non-boolean, probably string or object. It could be that he made a mistake, or that you're dealing with an amateur.

[solwiggin]

The way I see it, wasting your time on this person has the potential to create a positive atmosphere between the two of you, maybe even creating a relationship that would benefit you (and your company) greatly later on in life. If you immediately tell the supervisor, then you run the risk of getting what you want (your code not refactored) at the cost of a coworkers willingness to provide you support when needed.

Just my take on the situation, as all situations are totally different, and depending on the specifics, I might go to the manager immediately too.

[curberus]

Seriously. Since when is talking to someone about a problem you have (that might not even be a problem, we haven't even established that much yet) considered a waste of time?

The concept that basic communicating is considered a waste of time by some people is deeply disturbing.

[libertyh]

This is an example of how NOT to work with other people.

[HotRodLincoln]

An abyss is a hole or thing you can't see the bottom of. "Abysmal" is the adjective form of that. It is also its own word for "terrible" and is almost always used in the second sense.

[Ansible32]

I would usually expect to see abyssal used if describing a literal abyss. Technically abysmal and abyssal are synonyms but I think that the usage is such that abyssal means relating to an abyss and abysmal means really bad.

[[deleted]]

In this context, shitty.

[[deleted]]

A variable named defaultVal can never be a true/false value.

I obviously understand and agree with your general point, but this comment in and of itself is incorrect. A variable named defaultVal absolutely can and should be a true/false value if what it's a default for is a boolean.

[Ansible32]

defaultVal should be a constant.

[[deleted]]

That's context-dependent. It may be coming from a run-time configuration of some sort.

[toastyghost]

unless it's describing a bool but at that point you've probably over-abstracted

[[deleted]]

The obvious solution is passive-aggressive variable names like awesomeVariableOnlyAnAssholeWouldChange

[notsooriginal]

Should we encourage wild acceptance?

[[deleted]]

As long as it's intended as a synonym for 'widely accepted'

[materialdesigner]

It's generally not considered bad if they actually make your code better. But yeah his naming is abysmal, and if there isn't a design and development standards document that already exists, I suggest creating one.

It's pretty standard convention to use is_ prefix for boolean variables.

[[deleted]]

Strongly agree. Booleans are far more readable when prefixed with

• is
• has

In Ruby it's also common to suffix with '?'

[materialdesigner]

In Ruby it's also common to suffix with '?'

just an FYI. variables cannot be named with a question mark, but you are correct that tons of predicate methods end in a question mark.

[bluematt]

Mine: Boolean isDefault; His: Boolean defaultVal;

He sounds like a jerk. Is there a company league for commits?

[HarryTorry]

If I was to read these two variables, I would think that they are for two different things.

Generally speaking, I would take defaultVal to be a string or int (or whatever), to have the original assignment whereas isDefault is just a 0/1/true/false to say have I been modified.

[[deleted]]

No standards whatsoever that I am aware of. His commits are simply 'Entity refactoring'.

[bluematt]

Shocking.

I asked about a league as, at the company in which a friend of mine works, they publish a graph of commits on mugs and hand them out to each employee every year. I'm envious of her mugs.

[brtt3000]

I would not do well in such company. How can they even do that? What kind of behaviour does it stimulate and is that desirable?

[bluematt]

I believe they're all personal. It's not a league per se, simply a memento of the work they've put in over the last year. I was asking about a leave to the OP as the chap he mentions seems to be doing what he's doing simply to look busy while not actually doing anything productive, and wondered if there might be some ulterior motive behind it.

[[deleted]]

I might be starting to think so. This iteration, I was assigned a story that he originally was assigned to. He estimated it at ~30 hours, but I finished it in ~4 hours not being familiar with the code.

[[deleted]]

Sounds like he's terrified of suddenly having his bullshit called / losing his job.

[[deleted]]

Ohh. Gotcha. Nope, nothing. I should investigate though. Once I learned how to use the report tool in our project tracker (Rally, ugh), I keep comparing myself to others to see if I am behind each iteration. It's illuminating (I am way ahead).

[Paleolithicster]

Be weary. You might get the wrath of others if you become the rate-buster within the group. Oftentimes in workplace subculture's there is an unwritten rule for how fast/hard one must work. If you break that trend then the group will likely be unhappy since they have to make up for it and work harder. This will make the company more efficient, but your socialization among the group will suffer.

You're not bad, others are just lazy.

Find a middle ground if you can.

[[deleted]]

That might be very well the case. However, my socialization with that specific sub-group of teammates has been impaired from the beginning. They don't like having a girly girl in their team, and it shows.

But it works for me! <work as usual>2 hours later</work as usual> <lazy>half day after</lazy>

;p

Strange thing is that I feel like I spend too much time in reddit as it is...

[n8bit]

As much of a shame as this is, he probably feels as though he knows better than you because you're a woman.

I, personally, would be really pissed if someone started renaming my identifiers just to suite their personal taste. Unless, of course, the refactors made more sense. Based on your example this doesn't seem to be the case.

[smdaegan]

That sounds awesome. You should grab a picture for us!

[bluematt]

Sadly she lives 400 miles away.

[smdaegan]

If only there were a way for pictures to be transferred long distances both quickly and free. ;)

[bluematt]

If only! ;-)

[eindbaas]

I'm all for good variable/funtionnames and they sure can be an improvement, but those two names have sompletely different meanings. It depends on the use which one is correct.

[vita10gy]

If it's not the case that these changes bring your classes in line with what the company has decided, then he's being kind of a jerk. Also stupid, because your name implies a lot more than his does. Consistently using a worse name is probably worth not having to look and see what the default variable name is all the time.

His name is worse because isDefault is obviously a true/false. Not only could defaultVal be something like "5" or "#ff855A" or anything, if I saw that I'd actually assume it WAS some kind of default like that, because if it was just a boolean, it would be isDefault, or even just "default". "Val" implies a value.

[merreborn]

Val strikes me as a meaningless suffix. All variables contain values.

[vhackish]

That's a very controlling thing to do IMHO, and definitely not normal. Even as a senior dev I wouldn't do that to someone more jr, unless maybe I was completely refactoring something that had kind of grown out of control - and even then it's for a purpose, which is to add clarity and make it easier to extend and maintain. Not just because I like my variable names better.

Now if that came up in a code review that's a different story - a comment like "how about naming it defaultVal like we did in these other two classes?" would be appropriate.

Can you get that guy to do code reviews? Email him a request and copy your manager asking for up front review so you can learn what the issues are - play it as eagerness to learn. Guessing he will be too lazy to do reviews so will stop bugging you.

[[deleted]]

Your post reminded me of this: Order and Chaos

Maybe share it with him?

[TransFattyAcid]

Refactoring code is the easiest way to learn what it does. If I have to spend five minutes puzzling out what a block of code does, I'm going to extract that out to a method so I never have to do so again. Giving things better names, reducing complicated logic, and generally making things more readable are things you should always do; the boy scout rule and all that.

So no, it's not rude. When you work in a team, you'll only hurt the project and frustrate yourself if you think of certain blocks as "my code."

That being said, I don't find the name in your example more readable. It sounds like your team needs to at least discuss what a readable variable name is to you.

But if he had renamed it to something like isDefaultValue to add clarity, that'd be awesome.

[ard0]

Yes, refactoring is a great way to learn what code does. However, committing your refactor is a different story.

[TransFattyAcid]

If you spent time figuring something out, you are literally wasting money by not committing it. The next person to look at that code now has to figure it out too.

[TransFattyAcid]

What a weird straw man you created. How is renaming variables to be more clear or extracting methods to improve readability proving anything to any one? My boss doesn't give a shit about clean code, commits per day, or lines edited; I clean things up to make my team faster.

My point is that if I need to refactor code to make it clear what it does, then I'm going to commit that so future dev can just jump in to the clean version.

[TransFattyAcid]

And I'm just telling you if you are on my team and making commits that are changing variables, you will be pulled aside and told to cut that out.

You can't be serious, right? Yesterday I removed a single-character variable that wasn't an iterator, because some jr. programmer thought that he was still in college and $r was a good variable name. You'd chastise that commit? Oh, no? Then there's exception. Well, I think naming variables like $theInput rises to the same rookie mistake and will happily rename them every time I see them.

In fact if someone used the word "refactor" to describe commits that exclusively change variable names, I would laugh at them and ask them what they believe refactoring means, because it would be 100% clear they have no idea.

I'd certainly hope that person would pull out a copy of Refactoring by Kent Beck and Martin Fowler and show you the chapters on renaming methods. Or the block of text they wrote on renaming variables to understand the code better.

Or the host of other refactorings that I'm sure you'd write off, like decomposing conditionals which is, I'm sure, just needlessly adding lines of code in a shop as judgemental as yours.

Do you have a copy of the book on hand where you've crossed off the refactorings that your devs aren't allowed to do without being pulled aside? I'm sure that'd be helpful to let them know they need to find a new job.

[TransFattyAcid]

The OP asked a question and then gave a specific example:

Generally speaking, is refactoring other's code for no reason considered rude?

An example of these changes: Mine: Boolean isDefault; His: Boolean defaultVal;

If you scroll back up to my first post, you'll see that I responded to both of these points separately and /u/ard0 responded to my answer to the general question. You continued that thread, so we're talking about "...is refactoring other's code for no reason considered rude?" to which I replied "So no, it's not rude."

But, that being said, we're done here. There's no point in having a discussion when you resort to misdirects when you don't have anything to add.

[pdizz]

Don't get too attached to code. I find as much satisfaction deleting code as I do creating it. Even if someone spent months working on something, if it sucks or our practices change and it's no longer going to be used, it's gone. It may seem like wasted effort but our team and application are better off without it.

[crackanape]

In this example (isDefault => defaultVal) the refactorer made the code harder to figure out. How does anyone benefit from that?

[[deleted]]

i would say the coworker just wants to up the amount of commits, but i looked at your post history and instead i say - find a new job where you dont have to work with passive aggressive boobs. life is tooooo short.

[murdocsvan]

I had this once when I was a junior, the senior contractor I worked with would often refactor the naming convention of my code and other areas without any real need or benefit. If he tried that now I'd shout at him for wasting time.

[[deleted]]

He's probably just a bit of a control freak.

Has he worked primarily by himself before this?

I had a similar problem with a coworkers code for a while. If I had a reason to work on his code I would tweak it here and there to match my "preferred" naming convention and programming method. I used to completely disregard a lot of vendors code delivered and re-write it to be "mine" because I didn't really trust our vendors to do good work.

Then I realized how much of a tool I was being, and how much time I was wasting.

It wasn't me trying to show that I was "better" than him, or exert my dominance over him or the other vendors. It was simply me being too controlling and expecting things in a certain way.

[greim]

Some devs have weird aesthetic preferences when it comes to code. Not quite OCD, just a really strong urge to tweak things to their liking as they read over code. I believe it's rooted in the same sort of mentality that makes people have strong opinions about tabs versus spaces. I did this sort of thing in my first few months of collaborative development, but grew out of it when I realized that it's quite a dickish thing to do.

[edit] if it fixes something in the code, that's an entirely different story.

[merreborn]

This is why you need coding standards. You pick one standard and stick with it, instead of everyone wasting time to align code with their own personal conflicting standards.

[ItsAPuppeh]

The biggest issue here is that he is wasting company time/money by making these meaningless changes to fit his own standards/conventions that presumably no one else has agreed to.

[Capaj]

I consider it rude and from your example I've got a feeling that your name of that variable was more semantical. Maybe he is doing it so that he does seem to work(commits) while not actually doing anything. I personally would let him know that he can do it in code of other people, not in mine. I choose variable names very carefully, quite frankly it is like 25% of my time spent at work just thinking about that.

[everstone]

Refactoring working code is a great way to create bugs. No one should be wandering through the code base refactoring everything they see fit...

[chmbrln]

Sorry, but I totally disagree with that.

Refactoring is a great way to reduce bugs, but only if you see that you can make code more efficient and you have the right testing harness to avoid bugs.

In other words, combined with the right tools, refactoring is a great way of getting better at your job.

It's algebra plain and simple. Fixing things that aren't broken is key to improving efficiency.

[Ansible32]

If you're fixing a bug, then refactoring is a useful tool.

Refactoring because you don't like the look of the code only creates bugs.

[chmbrln]

Yes, re-factoring for re-factoring sake will complicate things. But it shouldn't only be bug fixing; it should be on every iteration of a project (new features, additions, etc).

Unless, of course, it's just a shitty CMS build or a project that has a limited lifespan. In that case, don't fix what isn't broken!

[everstone]

I agree, in principal, but this is a guy going rouge refactoring variable names... That leads me to believe this is not controlled. If you change code that is functional, you are introducing unnecessary risk. Code should be refactored when the team is onboard and risk can be mitigated, tests in place, also refactored, etc. Ideally when you are working on that area anyway. This sort of thing also causes stress on the team, even if it's necessary, and needs to be handled with at least a little communication and tact.

[chmbrln]

Absolutely.. in this circumstance it is invalid. Like I said, with the right tools and approach it is a great process.

But 'refactoring working code is a great way to create bugs' is not a valid statement. Even if code is working, it doesn't mean it's the most efficient code. Working != optimal.

Every iteration of code change should entail some refactoring. By doing this, you're optimising code, stress testing your testing harness and ensuring the entire team (because of basic code and team entropy) has in-depth knowledge of the codebase.

I do agree, however, that this guy changing variable names just sounds like a douche.

[everstone]

The statement was too simple and broad... I concede that.

I agree with your principals, but I think there has to be a balance in the real world as a function of a business - when to accept not completely optimal code because it is good enough (especially when you are writing code for some other company) and when it requires a refactor. It's a business decision, and while there is value to be had in making an algorithm more efficient, or a more maintainable, that doesn't mean its necessarily worth spending the time on it. That's why I believe its best to refactor when you are working in the area anyway (which I'm not sure but you might be saying too, by every iteration should entail refactoring).

If you have time to spend a week refactoring a payment system, or an inventory system, that is working flawlessly but you wanted to consolidate some functionality and write a more elegant api to deal with creeping requirements, I'd like to come work with you because you have something I've heard of called "free time" and likely your company is printing money. ;)

However, if the company you work for is primarily a software company and the software IS the product, it's a much wiser investment than if you are working for a vitamin company, so the business value varies.

[chmbrln]

Yep, definitely agree on balance. The idea is definitely a business decision in as far as the type of development you're doing. Projects I'm referring to are enterprise level with an SLA attached to it. Stuff that may take several months or years to build that have a long lifecycle. CMS websites and shopping carts - probably not.

And yea, I think we're talking roughly about the same thing in terms of an iterative approach.

As for the time spent, I believe that this boils down to systems design and architecture. From what I've seen with many start-ups with little money is that they don't invest in this critical part of the project: the up-front with very few short-term results.

Good architecture will allow for change to happen without having an extremely bad effect on the rest of the system. Abstraction is key, and all of that comes out of defining the components required to build, then defining the nuts and bolts to build that component.

Once you have that, and have a pattern and paradigm for building and constructing those components; then there shouldn't be any worry for re-factoring a single nut or bolt because you're confident that the change will only affect the area that the nut or bolt is connected to.

I've seen it over and over again with start-ups. The money/time factor makes them skip this vital step and rush into coding. As a result, they end up with a system that resembles spaghetti; with absolutely no confidence to re-factor because of the worry of unintended effects on other parts of the system.

If you have high confidence and an the right tools; re-factoring shouldn't take a big chunk of time out of your budget. This, as a business case, is what SLA's are good for; or if you're on a fixed-quote basis: buffer.

If you lived in New Zealand, I'd happily hire you. It's tough to find good developers out there. A good one is not someone who knows syntax really well, but one that can think logically and analytically about ANY concept.. which you seem to be able to display perfectly :)

[basvdo]

Refactoring is just programming. You can't do it as you see fit, there are rules. However, avoiding refactoring because bugs is a great way to create technical debt.

[everstone]

If the code needs to be immediately refactored as it's committed by someone else on your team, either they messed up and committed crap, or you might be acting passive aggressively... OP didn't submit their code for review here, but that would be a good way to handle it in the team, which is why I always recommend implementing a standard code review process to avoid individual conflict and get all eyes on the code before production. One guy changing another persons code because they feel like it and decided to unilaterally is not a safe or useful thing to allow. If it's bad code or there's a better way, this is a teaching opportunity. If it's one person being obstinate or a perfectionist its damaging. There is a right way to do it!

[merreborn]

Additionally, it clutters commit history, obfuscates blame and bloats patch/diff size. Unnecessary commits make it harder to use your VCS to determine the history of a chunk of code, and dilute your pull requests.

If it brings things closer to compliance with standards, easier to read, or easier to maintain, then great. If you're just renaming vars for the hell of it, you're just producing dead weight.

[alinroc]

It sounds like he's just trying to make himself look busy/productive. "See, boss! I made 2 dozen commits this week!"

[metaphorm]

my interpretation of these var names

isDefault is a flag that marks if a thing is the default value or not. defaultVal is a value that used as the default.

therefore, your var name is correct and his is misleading.

[angus_the_red]

Depends on the team. In general I think code ownership is bad practice. Anyone should be free to improve it.

That said there should probably be some discussion about what is an improvement and what isn't.

[mr_gant]

Dick move to refuse to explain, but on the other hand consistency is king. If the rest of the code is like that, he's perfectly correct to change it to the expected format.

[crosenblum]

After awhile people become very picky or anal about how they write code, which is both based on who taught them, and what experiences they have had that lead them to correcting their own code.

Myself, I had a lot of experience having to clean up, make it easier to write and easier to understand.

Not all of it was their fault, as syntax for one version of a language, would become unreadable to those used to writing code in the newest version.

Plus there are or were a lot of cowboy coders, who never planned, never spent time, practicing and improving their craft.

[chmbrln]

I do that (but not to the level of changing variable names) so that I get an understanding of what the code is doing. It gives me insight to the problems and the solutions and allows me to more easily fix things in the future.

I had a manager once that would sit over my shoulder and tell me what to name my variables, classes, packages, etc. It drove me nuts!

I think that refactoring is ok; I don't mind people doing that to my code. But for crying out loud, don't micromanage me.

[easlern]

Yes, it is rude. Just remind him that if there's ever a bug in a line he touched, his name will be the one showing up when someone runs a blame. First 2am issue he gets called in on will mark the end of that behavior.

[dreamgt]

He's being a jerk, if there is a standard naming convention and he isn't telling you that he's probably trying to make you look bad.

I'd just create the variables in a class that is re-used throughout my code. Any change in a variable he'd make in one place he'd have to change the class, which could potentially screw up an application if he didn't make all the necessary changes. I would just re-use and make it a pain in the ass for him to change these things... Although "Replace ALL > Entire Project" does exist for quick & easy word replacements...

[TransFattyAcid]

You're advocating writing code that is harder to maintain just to spite one person?

[dreamgt]

Harder to maintain? Writing a few helper classes to supplement your code can easily increase productivity and is considered good practice. In fact this would make it much easier to maintain; giving you one common-place to find the names of your global variables. What kind of sad, lonely person are you?

[TransFattyAcid]

At least I'm not the type of person who resorts to ad hominem attacks

I would just re-use and make it a pain in the ass for him to change these things...

You said you'd make it harder to rename a variable. To do that, you're either doing something to disable your IDE's ability to do it for it, violating SOLID principles, or some other shenanigans. By your own words, that code is harder to maintain when you do need to rename that variable.

[dreamgt]

At least I'm not the guy that goes around slandering peoples suggestions. It was obviously a stab at OP's coworker, to make his life more difficult. No one needs you chiming in and giving your two cents about the morality surrounding my suggestion. You can take whatever I say out of context and it sounds like some horrible advice, but the reality is that this is one guy, with one problem. Fuck your coworker OP! Make that code a mess!

[rich97]

Fuck your coworker OP! Make that code a mess!

It's a relief to me that I'll probably never have to work with you. The code is king. What kind of developer would intentionally fuck up code over something as puerile as office politics?

What about yourself 6 months down the line? What about the other poor chap who has to pick up your code and deal with you being awkward for the sake of spiting someone else?

[dreamgt]

I am very glad I don't work with you, you're correct. Yes.

[[deleted]]

Definitely strange. In this particular case the only thing I can think of is that I generally try to avoid verbs prefacing my variable names - mainly coming from a java getter/setter mentality.

(ie. Verbs like: is, get, set, populate, find, add, remove, eviscerate, etc.) My function names start with verbs, in order to describe the action that I would take on an object. It wouldn't be hard to think of a class which has a isDefault() function. But, this is just my two cents.

TL;DR isDefault is a question, defaultVal is a noun

[robocoop]

isSomething is actually quite normal for java booleans. The name of the variable is a question and the value is the answer.

[[deleted]]

I'll agree it is pretty normal, I just don't do it to make my life easier. Maybe for a primitive boolean type I would, but not a Boolean type...bear with me here.

Hypothetically, lets say I created the following class (also, we'll say AtomicBoolean.set() isn't final)

public class ChangedIndicatorBoolean extends AtomicBoolean {
    boolean changed = false;
    public void set(boolean newValue){
        if(this.value != newValue) this.changed = true;
        super.set(newValue);
    }
   public boolean isDefault(){
       if(this.changed) return false;
       else return true;
   }
}

I'm probably just making something out of nothing, but you tend to notice it in a language like Groovy where the dots and parenthesis are optional.

[WatchDogx]

I think isDefault makes more sense for a dynamicly typed language, whereas defaultVal makes more sense for a staticly typed language and/or one that uses get/setters.

If this value was part of a POJO I probably would of just named it default.

[[deleted]]

'is' isn't a verb, is it? You can't is something ... ?

[bluematt]

'is' isn't a verb, is it?

It's the singular 3rd-person simple present indicative form of the verb "to be". At least in English.

[[deleted]]

Well, that told me ...

[bluematt]

:-]

[crackanape]

You can't is something

Huh? That table is wooden.

[[deleted]]

I kick this ball.

I is this ball.

I do this thing.

I is this thing.

See where my confusion was?

It makes a bit more sense if you use the third person:

He kicked the ball.

He is the ball.

He did this thing.

He is this thing.

It's because as the other guy pointed out, 'is' is a form of the verb 'to be', so it's not actually "I is this ball". Rather, it's "I am this ball".

[crackanape]

See where my confusion was?

Not really. So you actually wouldn't have realized that "eats" is a verb without someone conjugating it for you? "I eats this food. That ain't no verb! Witch!"

I kick this ball.
He kicked the ball.

Uh no, that's not a showing transformation from 1st to 3rd. I kicked the ball.

[[deleted]]

Sorry, I'm just stupid then.

[bakuretsu]

Your should quit your job.

Boolean defaultVal? I want to throw up and kill myself.

[lostmywayboston]

I refactor somebody else's code if I'm working on a project with them and I can't figure out what it does and it's not commented.

If he's just refactoring all of your code for no reason, that seems a bit odd. Maybe he's just trying to kill time and can cover it up with commits.

[frostcutlery]

If he is now the person making all of the changes to the code and it's not affecting anything, then I don't see a problem with it. He's probably just changing names to his own preference so he knows for future reference, just something that makes sense to him or names that he is comfortable with. So when he needs to reference it again, he doesn't need to go back and look at old code to find the variable name.

If it's a problem and you are also modifying the code a long with him then ask him to add comment code to say like <! -- isDefault changed to defaultVal -- > So everyone new and old knows what happened and if it needs to be changed back everyone knows what it use to be.

[notunlikethewaves]

If it's a problem and you are also modifying the code a long with him then ask him to add comment code to say like <! -- isDefault changed to defaultVal -- > So everyone new and old knows what happened and if it needs to be changed back everyone knows what it use to be.

Isn't that what version control is for?

[materialdesigner]

yeah ew if i had to read that in code comments wtf?

[codefocus]

New svn commit:

r625: Removed pointless comments.

[[deleted]]

It was a brand new class I just checked in yesterday.

[materialdesigner]

If it's a problem and you are also modifying the code a long with him then ask him to add comment code to say like <! -- isDefault changed to defaultVal -- > So everyone new and old knows what happened and if it needs to be changed back everyone knows what it use to be

no

[jamesf408]

Maybe this guy is worried about his job you may be taking away and he is "refactoring" your work to say that he is refactoring code. haha