|
Keetron posted:Massive rant was incoming but I cooled down. My first dev job I worked at a company where an infamous senior dev in another office would do this every few weeks. Nobody really wanted to start a fight. We used CVS, which doesn't track changesets. I wrote scripts specifically for grabbing various info about his changes so I could unfuck stuff. I actually enjoyed working there for the most part... AbsoluteLlama fucked around with this message at 03:19 on Feb 3, 2018 |
#
?
Feb 3, 2018 03:10
|
|
|
|
| # ? May 10, 2024 09:13 |
|
|
JawnV6 posted:This just seems like willfully talking past each other. The thing that will somehow, some way merged to master should be reviewed and squashed down to 1 commit. Not willfully, but maybe I did miss the point. I'll go back and read the op again. umm... if you're suggesting squashing several intelligible changes into one giant sprawling commit before asking for a review I would certainly not be in favor of that. Rocko Bonaparte posted:A secondary cultural thing I am battling in the scenarios I gave is that reviews should be for something being basically ready-to-ship. Let's say I do 50 lines to implement one unit of work towards feature X. I am liable to see "-1 Verify this doesn't do X." What we would sometimes do with stuff like this or major change requests is spin off a new ticket and promise to address it in that one. That way we got to keep our smaller commits and the code reviewer has confidence their, possibly legitimate, concerns will be addressed. I know I hate it when someone checks in stuff that breaks features that were previously stable.
|
|
#
?
Feb 3, 2018 03:16
|
|
|
LLSix posted:Not willfully, but maybe I did miss the point. I'll go back and read the op again. "OOOOOOooooh you got phrasing around of the minuscule differences wrong! Let's wholly focus on that!!"
|
|
#
?
Feb 3, 2018 04:41
|
|
|
LLSix posted:What we would sometimes do with stuff like this or major change requests is spin off a new ticket and promise to address it in that one. That way we got to keep our smaller commits and the code reviewer has confidence their, possibly legitimate, concerns will be addressed.  regardless.
|
|
#
?
Feb 3, 2018 05:36
|
|
|
Speaking of merge reviews, supposing you had a coding standing of "80 char max line length", would it be reasonable to reject a merge request with a line that was exactly 80 chars long on the grounds that it's 81 when you include the newline? That sounded completely insane to me. When someone wanted to reject my code for that, I asked around other members of the team, including the extremely weak team lead, and they wouldn't even talk to me about whether that was really how it worked. This was a remote job, which is why they were free to ignore my messages. This particular reviewer had a bad personality already and on another occasion had launched into a 20 minute rant (on chat!) when I said "I like XML because it has builtin schema validation"
|
|
#
?
Feb 3, 2018 15:09
|
|
|
rt4 posted:Speaking of merge reviews, supposing you had a coding standing of "80 char max line length", would it be reasonable to reject a merge request with a line that was exactly 80 chars long on the grounds that it's 81 when you include the newline? You can write a script that will reject any PR that has lines over 79 characters long. While doing that, analyze the codebase for lines over 79 characters that he committed. code:update, it seems my git installation is bad, let me know what your results were. Keetron fucked around with this message at 15:50 on Feb 3, 2018 |
|
#
?
Feb 3, 2018 15:42
|
|
|
rt4 posted:Speaking of merge reviews, supposing you had a coding standing of "80 char max line length", would it be reasonable to reject a merge request with a line that was exactly 80 chars long on the grounds that it's 81 when you include the newline? No, lol, this dude sounds abysmal. 80 character line limits are ridiculous anyway. It's 2018, in what world would you need to wrap on 80 character? If you're going to enforce line limits they should be longer.
|
|
#
?
Feb 3, 2018 16:06
|
|
|
80 char length limits are AFAIK a legacy practice from the old days. I don’t see a reason why it is still enforced.
|
|
#
?
Feb 3, 2018 16:33
|
|
|
Because some graybeards are also legacies from the old days, pretty much. I usually shoot for 120 nowadays and typically would let overruns slide in pull requests, unless there were a bunch of lines that went over or one line that was like 300 characters long. Yet another thing that an auto-formatter would've done for itself, had we had one.
|
|
#
?
Feb 3, 2018 16:38
|
|
|
All this merge talk makes me so glad I work at a company that says "lol gently caress branches".
|
|
#
?
Feb 3, 2018 17:20
|
|
|
Paolomania posted:All this merge talk makes me so glad I work at a company that says "lol gently caress branches". What is wrong with you
|
|
#
?
Feb 3, 2018 17:26
|
|
|
Limiting to 80 chars is good because it makes it easy to have two files open side by side. I also find that the code ends up being easier to read when it doesn’t do too much on one line. I guess I am the legacy graybeard. Get off my lawn kids.
|
|
#
?
Feb 3, 2018 17:37
|
|
|
The 80 character limit is a holdover from punch cards. Technology has moved on, and standards should go with it. Very long lines are bad and there should be a limit, but there's no reason to keep it below the 120-150 range.
|
|
#
?
Feb 3, 2018 17:54
|
|
|
It's not for tech reasons, it's for readability. My code has gotten way cleaner and easier to read since I limited myself to 80 characters. I don't make it a hard rule, cause sometimes a line needs to be long, but as a general rule of thumb it has served me really well.
|
|
#
?
Feb 3, 2018 18:01
|
|
|
Roll Fizzlebeef posted:Limiting to 80 chars is good because it makes it easy to have two files open side by side. I also find that the code ends up being easier to read when it doesn’t do too much on one line. You can have 2 files open side by side with 120 chars per line too. Of course, that would require a monitor larger than 600x480, which if you'd actually be a graybeard you would have the nickel for.
|
|
#
?
Feb 3, 2018 18:04
|
|
|
TBH I recently did 72 character (soft) limit, and being able to have 2 panels side by side on a 12" ultraportable is nice. If you are working with a proper desktop, lol, go for ~120.
|
|
#
?
Feb 3, 2018 18:07
|
|
|
Volguus posted:You can have 2 files open side by side with 120 chars per line too. Of course, that would require a monitor larger than 600x480, which if you'd actually be a graybeard you would have the nickel for. Lol. I think you meant 640 x 480 young one. I actually use 2x 1920 x 1080 monitors and 80 chars fits perfectly with a nice sized font. If you have too many chars on one line the font needs to be smaller for them to fit. Wrapping the lines sucks so I avoid that if possible.
|
|
#
?
Feb 3, 2018 18:19
|
|
|
Roll Fizzlebeef posted:Lol. I think you meant 640 x 480 young one. 72pt font is a bit big to be honest. If I were you i'd try to replace my eyeglasses.
|
|
#
?
Feb 3, 2018 18:24
|
|
|
Pollyanna posted:80 char length limits are AFAIK a legacy practice from the old days. I don’t see a reason why it is still enforced. 80 is still the default value for Java's checkstyle. Some places just may have never bothered to change the default settings. 80 chars w/ 4-space indentation just seems terrible these days as defaults. We set to warn at 120 and have a second declaration to error at 150.
|
|
#
?
Feb 3, 2018 18:32
|
|
|
IntelliJ has a ghostline at 120, I kinda stick to that.
|
|
#
?
Feb 3, 2018 19:21
|
|
|
2 space indentation is perfectly fine 
|
|
#
?
Feb 3, 2018 19:25
|
|
|
79 character lines, hard tabs, and 8 space tab stops or get out
|
|
#
?
Feb 3, 2018 19:32
|
|
|
leper khan posted:What is wrong with you Keep your changes small, your release cycles short, and your velocity high!
|
|
#
?
Feb 3, 2018 21:26
|
|
|
Nippashish posted:79 character lines, hard tabs, and 8 space tab stops or get out 79 character lines, 4 space tabs, 4 space tab stops.
|
|
#
?
Feb 3, 2018 23:09
|
|
|
e. e. cummings has nothing on y'all.
|
|
#
?
Feb 4, 2018 00:10
|
|
|
ratbert90 posted:79 character lines, 4 space tabs, 4 space tab stops. 4 character lines, 79 space tabs, 87 space tab stops
|
|
#
?
Feb 4, 2018 00:10
|
|
|
2 space tabs and youre only allowed to indent 3 times in a function
|
|
#
?
Feb 4, 2018 00:29
|
|
|
Use feature branches for stories that can't fit in one or two reasonably-sized commits. If you find this is most of your stories, consider finding a way to make them smaller. There are any number of reasons why you might not be able to develop on master, but in general it's a good thing to eliminate those reasons.
|
|
#
?
Feb 4, 2018 00:34
|
|
|
You watch and limit the number of commits? That's what a PR is for. To group them all together
|
|
#
?
Feb 4, 2018 00:37
|
|
|
KoRMaK posted:You watch the number of commits? No, it's not the quantity of the commits, but the size of the change.
|
|
#
?
Feb 4, 2018 00:37
|
|
|
Think of it this way: the risk of a change - i.e. the chance of pain in the form of a new bug or a regression or a merge conflict - is proportional to its size. This is both due to new/modified behavior and due to increased surface for conflict. This makes changes that branch off of mainline for an extended period the most risky. Better to factor your work into a sequence of small changes (and any story can be factored into partial units of small change) where you frequently merge changes from main while you work.
|
|
#
?
Feb 4, 2018 01:06
|
|
|
After keeping my projects independent and "off the board" for a year I finally had to start using scrum/TFS and it is the biggest waste of time. Takes more time to write stupid loving first person task descriptions than it does to do half of them. Also love 4+ hour weekly meetings and 40 minute standups every day.
|
|
#
?
Feb 4, 2018 15:05
|
|
|
Pedestrian Xing posted:After keeping my projects independent and "off the board" for a year I finally had to start using scrum/TFS and it is the biggest waste of time. Takes more time to write stupid loving first person task descriptions than it does to do half of them. Also love 4+ hour weekly meetings and 40 minute standups every day. You should have retrospectives where you can point out waste in the process.
|
|
#
?
Feb 4, 2018 15:24
|
|
|
Pedestrian Xing posted:After keeping my projects independent and "off the board" for a year I finally had to start using scrum/TFS and it is the biggest waste of time. Takes more time to write stupid loving first person task descriptions than it does to do half of them. Also love 4+ hour weekly meetings and 40 minute standups every day. yeah that happens with everyone once upper management decides that you have to be Agile, but wants like a ton of meetings. generally though: a) user stories should be higher level - shouldn't have to justify every task, just a goal you're working toward. b) everyone should just talk to people when they're having problems instead of waiting until the scrum to do it. that meeting is punishment for not taking initiative to work with your team. if people are actually using the meeting to communicate real information or be like "i'm blocked because i'm waiting for so and so to do his thing", your team is defective. similarly, poo poo like the scrum of scrums or other arbitrary meetings are punishment for not communicating offline. c) once you've reached step b), you'll still have to contend with all the sprint estimation stuff. the way to fix this is to say you're switching to kanban. with kanban you can fill out the same forms as scrum and use the same template, but the numbers reported don't actually mean anything, because velocity is meaningless when you just keep doing stuff until you run out of stuff to do.
|
|
#
?
Feb 4, 2018 21:19
|
|
|
Yeah, stand-ups where I work are timeboxed to 15 minutes tops. Scrum/agile works a lot better when management isn't interested in wasting everyone's time.
|
|
#
?
Feb 4, 2018 21:32
|
|
|
Volguus posted:You can have 2 files open side by side with 120 chars per line too. Of course, that would require a monitor larger than 600x480, which if you'd actually be a graybeard you would have the nickel for. I first learned to program in 256x192
|
|
#
?
Feb 4, 2018 22:47
|
|
|
Yeah, its all management deciding we need to be hip and cool. We more or less have two main dev teams and mine always gets our poo poo done before meetings - our updates take a minute apiece at most. The other team apparently only talks during these meetings. We regularly have to sit through 15-20 minute conversations between two people. Thankfully these aren't irl meetings because goddamn. Incidentally, dev team B was picked up from a dying company...
|
|
#
?
Feb 4, 2018 22:59
|
|
|
Fun game: see how many times in a standup someone says "(Let's|Can we) take this offline?" followed immediately by more discussion of the topic On a previous (worse) team of mine, our record was something like 6-7
|
|
#
?
Feb 4, 2018 23:37
|
|
|
Pedestrian Xing posted:Yeah, its all management deciding we need to be hip and cool. We more or less have two main dev teams and mine always gets our poo poo done before meetings - our updates take a minute apiece at most. The other team apparently only talks during these meetings. We regularly have to sit through 15-20 minute conversations between two people. Thankfully these aren't irl meetings because goddamn. Incidentally, dev team B was picked up from a dying company... For any given meeting I will evaluate whether it is relevant to me at all, and if not I will leave. If it's stand-up I just rein in any long involved conversations. Of course, this is what people expect me to do, and only one or two people have ever gotten offended (these people are incapable of perspective and think their issue is the #1 issue for everyone no matter how true that is anyway). If you have narcissist managers who will take anything you do along those lines as a personal insult, though, I feel for you.
|
|
#
?
Feb 5, 2018 00:52
|
|
|
|
| # ? May 10, 2024 09:13 |
|
|
Main Paineframe posted:Yeah, stand-ups where I work are timeboxed to 15 minutes tops. Scrum/agile works a lot better when management isn't interested in wasting everyone's time. We keep to 15 minutes unless something major comes up that needs to be dealt with. We also keep grooming and planning to 1.5 hrs max. None of this 4 hour bullshit.
|
|
#
?
Feb 5, 2018 03:00
|
|