|
awesmoe posted:1. You haven't explained why it's an approach that needs special-case approval It'd be horrible to cooperate on a file of that size, even if it somehow actually is highly cohesive. I can understand, which I sometimes do, putting a matching interface in the same file and stuff like that. But putting everything in the same file is atleast a horror to navigate which makes it a coding horror to me.
|
#
?
Dec 16, 2012 00:30
|
|
|
|
| # ? May 17, 2024 19:40 |
|
|
3000 line files are okay, and that fact by itself isn't really a problem. You could put a whole 50000 line program into a single file and it would be okay. Sometimes some things are just 3000 lines of stuff. I think our product has an administrative command line front end that supports basically manipulating everything. That involves a file that is probably about 3500 lines. It's a lot of code, and it's all in one class, and it does different things to a cluster, while handling a lot of error cases. It's complicated. You could arbitrarily put different functions in different files, but I don't see the point in that.
|
|
#
?
Dec 16, 2012 01:10
|
|
|
I'm not suggesting putting everything in the same file, because that would be incredibly stupid. I'm saying that firing a guy for adding 2 lines of error handling to a 2999 file is also incredibly stupid, and as the guy who originally said it has taken it back, I'd say he agrees. nielsm posted:This was Java. You know, where one file is typically one class. Geekner posted:It isn't about some bullshit dogma, but the fact that you think gigantic source files are A-OK quote:and unrelated classes should share a source file for convenience. Geekner posted:Not everyone who manages code is some dogma-sperg, 3k is just a point where 99% of cases you have someone doing something stupid. I'm willing to bet you aren't in the 1%. My whole point is that file length doesn't materially affect readability, and so it isn't a (major) factor in whether should be refactored/rewritten/is hard to maintain/whatever. IMO splitting up a well-designed class to satisfy an arbitrary metric is stupid. Look: If you had a difficult problem, designed some software as best you could, broke things down as clearly as you could, all that stuff, worked with the rest of the team to make sure everyone thought you were on the right track, checked in a solution that included a 3001 line file (of which say 500 lines were comments) and this guy fired you, would you think that was reasonable?
|
|
#
?
Dec 16, 2012 01:15
|
|
|
awesmoe posted:Look: If you had a difficult problem, designed some software as best you could, broke things down as clearly as you could, all that stuff, worked with the rest of the team to make sure everyone thought you were on the right track, checked in a solution that included a 3001 line file (of which say 500 lines were comments) and this guy fired you, would you think that was reasonable? You keep going back to this stupid point. Nobody said they would actually fire someone for breaking some arbitrary rule, going one line over whatever. In my first reply I said there were plenty of exceptions. Why are you sperging over a simple rule of thumb? You must have had some really terrible boss at some point if you think every little guideline is written in stone.
|
|
#
?
Dec 16, 2012 01:21
|
|
|
awesmoe posted:1. You haven't explained why it's an approach that needs special-case approval 2. Jesus Christ you can't take a joke 3. That's right it was a joke, were you really reading and responding to these one at a time, and it was only at this point that you realized I'm "not actually doing what you said you were doing"? Or did you just waste your time writing out these detailed responses in order to argue with no one? awesmoe posted:I was replying to the guy who said "I refactored a long file into 3 short classes".
|
|
#
?
Dec 16, 2012 01:26
|
|
|
Geekner posted:You keep going back to this stupid point. Nobody said they would fire someone for breaking some arbitrary rule, going one line over whatever. Jen heir rick posted:We have a new rule in my office. If you have a project with a 3000 line code file in it that was not auto-generated, you are fired. quote:In my first reply I said there were plenty of exceptions. Why are you sperging over a simple rule of thumb? Yes, I did, actually! He did things exactly like this, except not with firing, because I'm in a country with labour laws. A problem would occur, he'd pick an arbitrary metric from the wreckage, come up with (and enforce) a blanket rule to punish anyone who passed that metric, and was completely unwilling/unable to explain how the metric related to the problem, or how preventing the metric from happening would prevent the problem next time. It was extremely frustrating at the time, and it pissed me off to see someone else (claiming to) do the same thing. The reason it pissed me off so much, incidentally, is because it didn't stop the problems from happening. The lovely programmers on the team kept on cranking out lovely code because this guy didn't have any idea what mattered and what didn't.
|
|
#
?
Dec 16, 2012 01:36
|
|
|
Geekner posted:You keep going back to this stupid point. Nobody said they would actually fire someone for breaking some arbitrary rule, going one line over whatever. I would absolutely fire someone for writing, as described, an unbelievably repetitive and almost totally unreusable 3k class, but I might just be an OO-jihadist. Next you'll tell me he didn't even write tests for it! :faints: e: awesmoe posted:The lovely programmers on the team kept on cranking out lovely code because this guy didn't have any idea what mattered and what didn't. nontechnicalmanagers.txt Doc Hawkins fucked around with this message at 01:56 on Dec 16, 2012 |
|
#
?
Dec 16, 2012 01:54
|
|
|
awesmoe posted:
Who said the file contained "closely related functionality"? Unless by closely related you mean they're close together in the same file, and by functionality you mean they all do nothing of consequence. By the amount of words you use when you post, I'm gonna guess you have made a few 3000 line files yourself. That's the only reason you're defending this guy. Well you can hire him. He'll be looking for work soon. And you know what? I double take it back. I am gonna make a rule. Only the cutoff is now 3284, just to be even more deliciously arbitrary. No exceptions. I'll call it the awesmoe rule. I have more awesome stories to share if awesmoe would just shut up. He's ruined my flow. Jen heir rick fucked around with this message at 02:13 on Dec 16, 2012 |
|
#
?
Dec 16, 2012 01:54
|
|
|
I think this is the best summary of the issue:Geekner posted:Not everyone who manages code is some dogma-sperg, 3k is just a point where 99% of cases you have someone doing something stupid. I'm willing to bet you aren't in the 1%. Any time you see a 3000 line file yes there's always a chance it'll be fine, and written by a professional who really knows what they're doing, but most of the time it won't be at all, and is probably gonna be by someone coding in a pretty messy way, or someone who hasn't attempted to refactor a single thing.
|
|
#
?
Dec 16, 2012 02:12
|
|
|
Doc Hawkins posted:This person is an intern, right? Like, they've never really programmed before. Give me that at least. Fresh out of college. Rave reviews from all his professors. Must be a lovely college. I didn't really want him to do this project. I wanted him to tackle some easier stuff before he tried something of this magnitude. but my (sorta)boss went and gave it to him. He (sorta boss)doesn't really understand that not all programmers are equal, and figured anyone would do. He's also not very good at determining how difficult something is. In addition we have poor communication because he's out of the office a lot. Largely because of this incident, all coding decisions have to go through me now, and hiring decisions go through me too(orders from the big boss), but we're gonna have to work on the communication issue.
|
|
#
?
Dec 16, 2012 02:27
|
|
|
"updflwup" looks like something I would have written before I started really using classes. The idea is to make a certain set of variables show up in a regex search like this: KEYspecificVarKEY Then I could have all the associated variables show up with a regex search. I no longer do this. What might DFWL be?
|
|
#
?
Dec 16, 2012 02:59
|
|
|
Jen heir rick posted:Fresh out of college. See, this is why I only work at shops that do %100 pairing.
|
|
#
?
Dec 16, 2012 03:41
|
|
|
Doc Hawkins posted:See, this is why I only work at shops that do %100 pairing. Like all work is done paired? I've always wondered if pairing all the time existed in the wild.
|
|
#
?
Dec 16, 2012 03:48
|
|
|
ultramiraculous posted:Like all work is done paired? I've always wondered if pairing all the time existed in the wild. I've met people that work for places that do that, and they all love it. I don't think I could deal with it, though. Sometimes I just want to half-rear end an afternoon.
|
|
#
?
Dec 16, 2012 04:54
|
|
|
Doc Hawkins posted:See, this is why I only work at shops that do %100 pairing. Interesting idea. I like it!
|
|
#
?
Dec 16, 2012 05:17
|
|
|
Ithaqua posted:I've met people that work for places that do that, and they all love it. I don't think I could deal with it, though. Sometimes I just want to half-rear end an afternoon. Or listen to music, or take a walk and think something out on your own.. To be honest, if I want to design something with somebody, I just go ask. I'm not sure I'd want that to be the default/required option.
|
|
#
?
Dec 16, 2012 05:25
|
|
|
beoba posted:Or listen to music, or take a walk and think something out on your own.. I'll allow it, as long as you promise not to write code at the exact same time.
|
|
#
?
Dec 16, 2012 06:46
|
|
|
The hard part with pairing is that you have to get everyone on the same page. There can be some wildly different ideas about the coding process within a single team and pairing the wrong people up can cause problems. I've found that pairing can be awesome and that it can degenerate to one person typing by proxy.
|
|
#
?
Dec 16, 2012 14:47
|
|
|
thelightguy posted:The horror there is that the LDS church has created the specification for the most commonly used genealogy format, and purposefully crippled it to fit their moral standards. Well the original Gedcom format was introduced in 1984, before any countries had any notions of same-sex partnerships (in a legal sense). FamilySearch (a mormon company) are currently working on Gedcom X which does not have those restrictions. See here, it came up earlier in the thread: http://forums.somethingawful.com/showthread.php?threadid=2803713&pagenumber=370&perpage=40#post408911070 Carthag Tuek fucked around with this message at 16:01 on Dec 16, 2012 |
|
#
?
Dec 16, 2012 15:56
|
|
|
Doc Hawkins posted:See, this is why I only work at shops that do %100 pairing. I don't think I could handle that much pairing, but we do 200% code review for most development (everything goes through two rounds of review), and I certainly appreciate that.
|
|
#
?
Dec 16, 2012 18:23
|
|
|
Problem: the camera app on this Android cell phone requires access to the camera framebuffer. Solution: if you're Samsung, give everything unrestricted read/write access to all of memory. 
|
|
#
?
Dec 16, 2012 18:52
|
|
|
ToxicFrog posted:Problem: the camera app on this Android cell phone requires access to the camera framebuffer.  Goddamn, I guess writing their own kernel driver and ioctls for the camera was too much work.
|
|
#
?
Dec 16, 2012 19:28
|
|
|
Zhentar posted:I don't think I could handle that much pairing, but we do 200% code review for most development (everything goes through two rounds of review), and I certainly appreciate that. For a while at my job we had brand new people fresh out of college reviewing other brand new people's code.  That's not code review, it's a circlejerk. Needless to say, code quality plummeted.
|
|
#
?
Dec 16, 2012 21:05
|
|
|
ToxicFrog posted:Problem: the camera app on this Android cell phone requires access to the camera framebuffer.  Now that's really trying hard to be lovely. Holy poo poo. What the gently caress, Samsung  Seriously, what the hell. It couldn't have been more than a couple manhours of work to write a basic, lovely kernel driver for camera access 
|
|
#
?
Dec 17, 2012 00:40
|
|
|
Zhentar posted:I don't think I could handle that much pairing, but we do 200% code review for most development (everything goes through two rounds of review), and I certainly appreciate that. I once heard a guy observe that pair programming is really just code review in the limit. If feedback is good, then constant and immediate feedback must be the best! For some people.
|
|
#
?
Dec 17, 2012 04:26
|
|
|
The problem with pairing is that it's really full-on, and you don't get time to slack off and mull a problem over in your head. That "slack time" is important, both for morale and because it's better at producing creative solutions than going full-tilt at a problem. I would imagine that 100% pairing would be alright in a crunch, but outside of that it's probably better in moderation.
|
|
#
?
Dec 17, 2012 05:21
|
|
|
Any further discussion probably belongs in a thread on process or Xtreme Scrum Kanban or whatever, but I will say that pairs definitely can mull over a problem together, they just do it in conversation rather than in silence.
|
|
#
?
Dec 17, 2012 06:50
|
|
|
Doc Hawkins posted:thread on process or Xtreme Scrum Kanban For $50k I'll contribute a seminar on Orthogonal Defect Planning Poker.
|
|
#
?
Dec 17, 2012 08:38
|
|
|
Today I had to make some changes to code a third party wrote for my company. The comments were just lovely:code:
|
|
#
?
Dec 17, 2012 15:23
|
|
|
It's hard being a developer when you're colorblind.
|
|
#
?
Dec 17, 2012 15:33
|
|
|
Maybe the third party uses a big-endian machine.
|
|
#
?
Dec 17, 2012 16:06
|
|
|
BGR is really not all that uncommon if you're dealing with relatively low-level things.
|
|
#
?
Dec 17, 2012 16:17
|
|
|
The comment was simply wrong. It was blue.
|
|
#
?
Dec 17, 2012 16:42
|
|
|
Plorkyeran posted:BGR is really not all that uncommon if you're dealing with relatively low-level things. What why? I haven't worked with low level stuff in... a long time, but I really have no idea why you would want the order reversed like that.
|
|
#
?
Dec 17, 2012 23:31
|
|
|
Amarkov posted:What why? I haven't worked with low level stuff in... a long time, but I really have no idea why you would want the order reversed like that. Thats kind of like asking why you'd want little endian vs big endian. Windows bitmaps used to mostly be BGR, and GDI always was BGR. Old graphics cards always used BGRA. I have no idea why just like I have no idea why we never settled on a standard for endianness.
|
|
#
?
Dec 17, 2012 23:49
|
|
|
Eruonen posted:The comment was simply wrong. It was blue. I laughed.
|
|
#
?
Dec 18, 2012 00:54
|
|
|
awesmoe posted:Yeah, I'm not used to java so I'm not sure how common it is to put related functionality into the equivalent of unnamed namespaces. Are private classes a thing that people use? I'm not a java guy. Three related programs doing slightly different things, four files, thousands of lines of copy-pasted code. The fourth file turned out to be a template for further copy-pasting, should the three provided programs not do quite what one needed. (Code reuse!) Did I mention all the lines of code that were several hundred characters long? The longest nearly hit four figures. It's easier to do than you might realise when the only data structure you ever use is nested Vectors and you're allergic to storing common subexpressions in variables. Oh god the flashbacks
|
|
#
?
Dec 18, 2012 02:07
|
|
|
hobbesmaster posted:Thats kind of like asking why you'd want little endian vs big endian. The RGB model existed before computers though, and I was under the impression that that the colors were standardized in that order. (I could be wrong about that though, and I guess I probably am.)
|
|
#
?
Dec 18, 2012 03:17
|
|
|
There are compelling reasons to use private classes, or otherwise not break out every logical object into its own class. They are mostly relevant though when you are writing a library and want the public API to be extremely clean. If you have to worry about code obfuscation it can help a bit as well. Even in those cases where it can really help your API, most Java devs don't do it though. If you are writing a piece of software for yourself of your company, maintainability tends to be far more valuable. Breaking things out logically makes code much easier to maintain, and so it is the general style that wins out. Note that I am talking about private *inner* classes. As for the situation Soricidus described with multiple *top-level* classes... I have never seen a reason why you would want or need to do that.
|
|
#
?
Dec 18, 2012 03:30
|
|
|
|
| # ? May 17, 2024 19:40 |
|
|
Amarkov posted:What why? I haven't worked with low level stuff in... a long time, but I really have no idea why you would want the order reversed like that. code:The main reason it shows up in modern systems is due to a leaky abstraction of little-endianness. However, there's a few historical examples of big-endian systems that used BGR, and I don't really know why that'd happen (other than programmers loving up and thinking they needed to swap when they didn't or something).
|
|
#
?
Dec 18, 2012 04:24
|
|