Search Results

Search found 5 results on 1 pages for 'greengit'.

Page 1/1 | 1 

  • On improving commit practices

    - by greengit
    I was thinking about ways to improving my commit practices. Is there any co-relation between no. of source code lines and no. of commits? In a recent project that I was involved in, I was going at 30 commits per 1000 lines. One typical file from the project has these stats language: JavaScript total commits that include this file: 32 total lines: 1408 source lines: 1140 comment lines: 98 no. of function declarations: 28 other declarations: 8 Another file has these... Language: Python total commits that include this file: 17 total lines: 933 source lines: 730 comment lines: 80 classes: 1 methods: 10 I also think that no. of commits is more related to no. of features or no. of changes to the code and less to the no. of lines. The general git community motto is make short commits and commit often. So, do you really think about you commit strategy before you start the project. For that matter, is there anything like commit strategy? If so, what's yours?

    Read the article

  • Avoiding new operator in JavaScript -- the better way

    - by greengit
    Warning: This is a long post. Let's keep it simple. I want to avoid having to prefix the new operator every time I call a constructor in JavaScript. This is because I tend to forget it, and my code screws up badly. The simple way around this is this... function Make(x) { if ( !(this instanceof arguments.callee) ) return new arguments.callee(x); // do your stuff... } But, I need this to accept variable no. of arguments, like this... m1 = Make(); m2 = Make(1,2,3); m3 = Make('apple', 'banana'); The first immediate solution seems to be the 'apply' method like this... function Make() { if ( !(this instanceof arguments.callee) ) return new arguments.callee.apply(null, arguments); // do your stuff } This is WRONG however -- the new object is passed to the apply method and NOT to our constructor arguments.callee. Now, I've come up with three solutions. My simple question is: which one seems best. Or, if you have a better method, tell it. First – use eval() to dynamically create JavaScript code that calls the constructor. function Make(/* ... */) { if ( !(this instanceof arguments.callee) ) { // collect all the arguments var arr = []; for ( var i = 0; arguments[i]; i++ ) arr.push( 'arguments[' + i + ']' ); // create code var code = 'new arguments.callee(' + arr.join(',') + ');'; // call it return eval( code ); } // do your stuff with variable arguments... } Second – Every object has __proto__ property which is a 'secret' link to its prototype object. Fortunately this property is writable. function Make(/* ... */) { var obj = {}; // do your stuff on 'obj' just like you'd do on 'this' // use the variable arguments here // now do the __proto__ magic // by 'mutating' obj to make it a different object obj.__proto__ = arguments.callee.prototype; // must return obj return obj; } Third – This is something similar to second solution. function Make(/* ... */) { // we'll set '_construct' outside var obj = new arguments.callee._construct(); // now do your stuff on 'obj' just like you'd do on 'this' // use the variable arguments here // you have to return obj return obj; } // now first set the _construct property to an empty function Make._construct = function() {}; // and then mutate the prototype of _construct Make._construct.prototype = Make.prototype; eval solution seems clumsy and comes with all the problems of "evil eval". __proto__ solution is non-standard and the "Great Browser of mIsERY" doesn't honor it. The third solution seems overly complicated. But with all the above three solutions, we can do something like this, that we can't otherwise... m1 = Make(); m2 = Make(1,2,3); m3 = Make('apple', 'banana'); m1 instanceof Make; // true m2 instanceof Make; // true m3 instanceof Make; // true Make.prototype.fire = function() { // ... }; m1.fire(); m2.fire(); m3.fire(); So effectively the above solutions give us "true" constructors that accept variable no. of arguments and don't require new. What's your take on this. -- UPDATE -- Some have said "just throw an error". My response is: we are doing a heavy app with 10+ constructors and I think it'd be far more wieldy if every constructor could "smartly" handle that mistake without throwing error messages on the console.

    Read the article

  • Laptops or Notebooks in a meeting? [closed]

    - by greengit
    Is taking the laptop to the meeting a good idea? Of course, the project leader needs to have one -- but the programmers -- especially those who only need to get straight instructions on what to do next on the project -- do they need to take laptops? I feel it takes longer to save notes in a software -- and it's lot easier to just jot down "things to do" in a simple note book. That way you can keep up with the discussion and not lose track of what someone else is saying by spending too much time entering text in the machine.

    Read the article

  • What's the most important trait of a programmer desired by peer programmers [closed]

    - by greengit
    Questions here talk about most important programming skills someone is supposed to possess, and, a lot of great answers spring up. The answers and the questioners seem mostly interested on qualities related to getting a better job, nailing some interview, things desired by boss or management, or improving your programming abilities. One thing that often gets blown over is the genuine consideration for what traits peers want. They don't much value things like you're one of those 'gets things done' people for the company, or you never miss a deadline, or your code is least painful to review and debug, or you're team player with fantastic leading abilities. They probably care more if you're helpful, are a refreshing person to talk to, you're fun to program in pair with, everybody wants you to review their code, or something of that nature. I, for one, would care that I come off to my peers as a pleasurable programmer to work with, as much as I care about my impression on my boss or management. Is this really significant, and if yes, what are the most desirable traits peers want from each other.

    Read the article

  • Alternatives to Professional Version Control

    - by greengit
    We're teaming up with some non programmers (writers) who need to contribute to one of our projects. Now they just don't like the idea of using Git (or anything for that matter) for version controlling their work. I think this is because they just don't find it worthwhile to wrap their heads around the twisted concepts of version control. (when I first introduced them to branching and merging -- they looked like I was offending them.) Now, we're not in a position to educate them or convince them to use it. We're just trying to find alternatives so that we get all their work versioned (which is what we need) -- and they get easy workflow and concentrate on what they do. I have come up with some ideas... tell them to save their work as a separate file every time they make some non-trivial change, and then use a diff on our side to just track changes. write a program (in Python) that implements the "milestones" in CSSEdit in some way. About the project: It is a natural language processing system (written in C + Python). We've hired some writers to prepare inputs for the system in different languages. And as we evolve the software, we'd need those writers to make changes to their inputs (articles). Sometimes the changes are very small (a word or two), and other times big. The reason we need to version control those changes is because every small/big change in the input has the potential to change the system's output dramatically.

    Read the article

1