|
Sagacity posted:Jabor, just for reference, how big are the projects you are working on? Are they leaning more towards monolith or more towards micro? I assume the former, because then you will definitely have to start reasoning about separate parts of the same projects as black boxes. A bit over 500k LOC (not counting tests), tens of developers, multiple applications build from the same codebase. Not a huge project, but big enough that you can't really grok all of it at the same time.
|
#
?
Aug 4, 2015 16:43
|
|
|
|
| # ? May 16, 2024 19:24 |
|
|
zergstain posted:I always thought the reason for mocks was you want to test A, which uses C, but C hasn't been implemented yet.
|
|
#
?
Aug 4, 2015 18:25
|
|
|
I've got an ActiveMQ queue that's subject to all sorts of transient faults (network, file system, etc). 99% of the tests that use the queue don't care about most of its features (e.g. persistence), and the people who write those tests would be annoyed if their test failed because of some transient fault that breaks the queue but that otherwise wouldn't have broken their test. So, they get a mocked queue (pretty much just a standard ConcurrentLinkedQueue from java.util.concurrent) that isn't going to break on them.
|
|
#
?
Aug 5, 2015 01:26
|
|
|
So targets for mocking include Things That Break and Things That Don't Break?
|
|
#
?
Aug 5, 2015 01:40
|
|
|
JawnV6 posted:So targets for mocking include Things That Break and Things That Don't Break? Mocking is a strategy for isolating the code you want to test from code you do not want to test. It's great for simulating certain error scenarios that you may not otherwise be able to trigger.
|
|
#
?
Aug 5, 2015 02:17
|
|
|
More horrors of code, less missing the point.
|
|
#
?
Aug 5, 2015 02:26
|
|
|
loinburger posted:I've got an ActiveMQ queue that's subject to all sorts of transient faults (network, file system, etc). 99% of the tests that use the queue don't care about most of its features (e.g. persistence), and the people who write those tests would be annoyed if their test failed because of some transient fault that breaks the queue but that otherwise wouldn't have broken their test. So, they get a mocked queue (pretty much just a standard ConcurrentLinkedQueue from java.util.concurrent) that isn't going to break on them.
|
|
#
?
Aug 5, 2015 02:30
|
|
|
The only semantics that most of the tests care about, and the only semantics I'm replicating, are "add something to the queue" and "remove something from the queue." For that matter, they don't even care that it's a queue - they just want a source and/or sink that's not going to cause them grief. There are a few tests (other than the ones I've written) that care about transactional semantics or persistence or whatever, and they get a non-mocked queue.
loinburger fucked around with this message at 02:42 on Aug 5, 2015 |
|
#
?
Aug 5, 2015 02:35
|
|
|
Subjunctive posted:More horrors of code, less missing the point. At my first job out of college, I discovered that we were making a call to the database for every cell in some sort of a grid control. When I asked somebody about it, the response I got was along the lines of "well they kept changing the requirements on us, so we made it really slow as payback." In this story, "they" are the client services department, and "we" were the internal applications team. Our DBA was fairly new, and he spent a lot of his spare time figuring out where all the foreign keys and primary keys should have been all along.
|
|
#
?
Aug 5, 2015 02:44
|
|
|
In TYOOL2015:php:<?
function reader() {
global $GLOBALS;
...
}
public function validateDate($date, $format = 'Y-m-d H:i:s')
{
$d = \DateTime::createFromFormat($format, $date);
return $d && str_replace("0","",$d->format($format)) == str_replace("0","",$date);
}
public function validDate($date, $format = 'Y-m-d H:i:s')
{
$d = \DateTime::createFromFormat($format, $date);
if($d){
return $d->format($format);
}
else {
return "";
}
}
?>IT BEGINS fucked around with this message at 04:25 on Aug 5, 2015 |
|
#
?
Aug 5, 2015 04:23
|
|
|
Pet peeve: when camelCase names get capitals in the middle that aren't appropriate. A library we use has a namespace full of CSS colours and one of them is "DarkGoldenRod". The "rod" is not a separate word you shmucks!! I am extremely disproportionately irritated about this
|
|
#
?
Aug 5, 2015 14:31
|
|
|
you should be more triggered by the fact that the industry went with camel case instead of underscore case or hyphen case stupid_big_thing stupid-big-thing stupidBigThing StupidBigThing
|
|
#
?
Aug 5, 2015 15:12
|
|
|
Hammerite posted:Pet peeve: when camelCase names get capitals in the middle that aren't appropriate. A library we use has a namespace full of CSS colours and one of them is "DarkGoldenRod". The "rod" is not a separate word you shmucks!! I am extremely disproportionately irritated about this What if the color is supposed to be a rusty C3P0 dilz, did you ever think of that?
|
|
#
?
Aug 5, 2015 15:23
|
|
|
Hammerite posted:Pet peeve: when camelCase names get capitals in the middle that aren't appropriate. A library we use has a namespace full of CSS colours and one of them is "DarkGoldenRod". The "rod" is not a separate word you shmucks!! I am extremely disproportionately irritated about this You should seek help.
|
|
#
?
Aug 5, 2015 15:44
|
|
|
Hammerite posted:Pet peeve: when camelCase names get capitals in the middle that aren't appropriate. A library we use has a namespace full of CSS colours and one of them is "DarkGoldenRod". The "rod" is not a separate word you shmucks!! I am extremely disproportionately irritated about this Another peeve: People who misspell "schmuck".
|
|
#
?
Aug 5, 2015 15:53
|
|
|
comedyblissoption posted:you should be more triggered by the fact that the industry went with camel case instead of underscore case or hyphen case That is way too COBOL or PLI-ish.
|
|
#
?
Aug 5, 2015 16:05
|
|
|
Amberskin posted:That is way too COBOL or PLI-ish. You're right, it is inherently superior.
|
|
#
?
Aug 5, 2015 16:19
|
|
|
Everywhere I've worked and learned has been insistent that underscores only go in names of constants and typedefs. Constants in all upper-case and typedefs in all lower-case.
|
|
#
?
Aug 5, 2015 16:42
|
|
|
http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
|
|
#
?
Aug 5, 2015 17:25
|
|
only
|
Edison was a dick posted:http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf This is all very well, but generally one is not in a position of sitting down and deciding what convention to use, rather you have an existing codebase and consistency with what came before is much more valuable than "well some study showed that underscore names are 5.2% easier to read" Also I know I just posted to have a whinge about naming conventions but there was no call for making it into a camelcase vs underscores debate. 
|
|
#
?
Aug 5, 2015 20:26
|
|
|
There should just be one naming convention. Once a year, put it after defcon. Bring all the variables you need to name, have some lecture series and panels, etc.
|
|
#
?
Aug 5, 2015 20:30
|
|
|
Tangentially related: why are most languages still case sensitive? Has "String string" ever been anything but a code smell?
|
|
#
?
Aug 5, 2015 21:57
|
|
|
LeftistMuslimObama posted:Some of the teams at my company do Agile or scrums or whatever, and it all seems so loving dumb to me. What's so hard about going to work, and doing the poo poo you need to do at a pace that enables you to meet your deadline? Why do we need special names and paradigms for everything? Just do as much work as you can at a reasonable pace every day. Don't stop until the work is done. The end. I have never organized myself further than "Monday I am doing a code review, Tuesday I'm going to focus on getting a rough version of Module Y knocked out... etc", and I am easily 3x more productive than any of the Agile devotees I've met at work, and I turn out a lot fewer bugs than them too. Half the Agile disciple teams aren't even allowed to do big enhancements right now because they have too many bugs to fix. The trash the methodology devotees pump out is kinda expected, no? They're probably focusing way harder on their process than actually writing code. E: I do think that the methodologies have their place and do great things, but at a previous company they embraced scrum as their cure all instead of addressing the more major issues (lovely staff, poor data retention policies, etc. Hell they put a database belonging to the faa on a ram disk that then got corrupted and lost a month of data) Mellow_ fucked around with this message at 22:08 on Aug 5, 2015 |
|
#
?
Aug 5, 2015 21:58
|
|
|
NihilCredo posted:Tangentially related: why are most languages still case sensitive? Saying "still" presupposes that case insensitivity is an improvement and predominantly a feature of newer languages. Neither of these things are true. Incidentally, the case of "String string" and similar things isn't only related to case sensitivity - namespaces and lookup rules come into play, too. There are probably languages where you can have an instance of data type x which is named x and not have any problems (except confusion).
|
|
#
?
Aug 5, 2015 22:02
|
|
|
Surely one could make a font that adds a bit of space between a lowercase letter and its subsequent uppercase letter to make camelcase more legible.
|
|
#
?
Aug 5, 2015 22:07
|
|
|
NihilCredo posted:Tangentially related: why are most languages still case sensitive? Has "String string" ever been anything but a code smell? Well, among other things, "case-sensitive" means different things in different locales, leading to one PHP bug: quote:There is an odd problem with Turkish language and PHP. To cut it short, in Turkish there are "dotted capital I" and "dotless i" characters, and "i != I".
|
|
#
?
Aug 5, 2015 22:09
|
|
|
pokeyman posted:Surely one could make a font that adds a bit of space between a lowercase letter and its subsequent uppercase letter to make camelcase more legible. I'm not sure if this is a subtle troll to get people to spit bile over the implication that they might use a variable-width font. But it does cause me to wonder whether subtle, contextual changes to letter glyphs could enable what you're suggesting while retaining the character grid of a fixed-width font.
|
|
#
?
Aug 5, 2015 22:23
|
|
|
Blotto Skorzany posted:Saying "still" presupposes that case insensitivity is an improvement and predominantly a feature of newer languages. Neither of these things are true. I didn't mean to imply the latter (I'm aware of OLD-TIMEY LANGUAGES), but I do the former. I have curiously googled arguments for case sensitivity a few times, with poor results - many answers were just historical notes or mild technical obstacles. The most common actual argument seems to be "we can use case to convey information, such as whether a certain token is a constant or a variable", which is certainly true, but which doesn't require case sensitivity at all. Case sensitivity forces the user to adopt consistent casing, sure, but there's no reason why you should do it instead of leaving it to your coding environment, in the same way that you do with consistent indentation lengths (I hope). If there is a constant called BUTTS, typing "butts" should autocorrect to BUTTS instead of letting you declare a probably confusing homonym. Hammerite posted:I'm not sure if this is a subtle troll to get people to spit bile over the implication that they might use a variable-width font. But it does cause me to wonder whether subtle, contextual changes to letter glyphs could enable what you're suggesting while retaining the character grid of a fixed-width font. If you could directly manipulate font width, stretching them without changing anything else, what you suggest would be certainly be possible, but I suspect that that sort of manipulation would require a lot of painful hacking in your operating system's GUI libraries. Sticking to regular font size manipulation would avoid that problem, but if the width difference between 10pt and 9pt doesn't match the one between 9pt and 8pt, and I presume it doesn't, then you're boned. I guess you could avoid both problems with styling, e.g. bold the C in camelCase, but that looks like rear end.
|
|
#
?
Aug 5, 2015 22:40
|
|
|
I guess a (more or less) subtle color hue change for each segmet of a camelcase would suffice:
|
|
#
?
Aug 5, 2015 22:43
|
|
|
NihilCredo posted:I didn't mean to imply the latter (I'm aware of OLD-TIMEY LANGUAGES), but I do the former. I have curiously googled arguments for case sensitivity a few times, with poor results - many answers were just historical notes or mild technical obstacles. Possibly relevant (specific to truetype fonts in windows MFC) Using a smaller font size would look bad I imagine, but it is possible that using a slightly smaller font size and vertically stretching it might look okay. A variation of Tank Boy Ken's idea of colour would be to give capitals a slightly different hue.
|
|
#
?
Aug 5, 2015 22:53
|
|
|
NihilCredo posted:Tangentially related: why are most languages still case sensitive? Has "String string" ever been anything but a code smell? I think there's a pretty good argument for not treating globAllocations and globalLocations as the same variable. (example courtesy of this MonocQc post)
|
|
#
?
Aug 5, 2015 23:24
|
|
|
Type and symbol names changed, but otherwise unaltered:code:
|
|
#
?
Aug 6, 2015 01:05
|
|
|
VikingofRock posted:I think there's a pretty good argument for not treating globAllocations and globalLocations as the same variable. (example courtesy of this MonocQc post) That's a great example, which makes a pretty good argument indeed! It just happens to be an argument for case insensitivity. A case-insensitive language won't let you define globAllocations at all, if globalLocations already exists in the same scope. You'll get a nice big compiler error and squiggly line. A case-sensitive language, on the contrary, will happily let you define both. And then, if at any point your cheeto-encrusted fingers hit Tab on the wrong autocomplete entry, or your caffeine-reddened eyes miss the tiny case difference, the program will raise no objections and will compile and run just fine (barring a lucky type mismatch error).
|
|
#
?
Aug 6, 2015 01:35
|
|
|
Most languages let you shadow variables or at least global variables. You'd get a warning for that, but there's also function overloading, method names. Case sensitivity just makes everything more inconvenient. Being able to write String string; is a good thing. The more modern thing to do is to not only be case sensitive, but to have mandatory case conventions followed, like capitalization for type names, to the point where capitalizing or lower-casing a word could have direct semantic consequences. sarehu fucked around with this message at 01:58 on Aug 6, 2015 |
|
#
?
Aug 6, 2015 01:55
|
|
|
NihilCredo posted:Case sensitivity forces the user to adopt consistent casing, sure, but there's no reason why you should do it instead of leaving it to your coding environment, in the same way that you do with consistent indentation lengths (I hope). If there is a constant called BUTTS, typing "butts" should autocorrect to BUTTS instead of letting you declare a probably confusing homonym. Literally every ide worth its salt already does exactly what you want here. Try typing in something with the wrong case and then hitting your autocompletion key. Also, every language worth its salt will yell at you if you suddenly start talking about a new variable you didn't explicitly declare somewhere.
|
|
#
?
Aug 6, 2015 01:55
|
|
|
NihilCredo posted:(barring a lucky type mismatch error). You mean a typical type mismatch error.
|
|
#
?
Aug 6, 2015 01:58
|
|
|
NihilCredo posted:Tangentially related: why are most languages still case sensitive? Has "String string" ever been anything but a code smell? In Haskell, casing is syntactically meaningful. All constructors (both type constructors and value constructors) must have their first letter capitalised, and all variables must have an initial lowercase letter. This makes parsing easier for both man and machine. I base this opinion on also having programmed in Standard ML, which has no such rule, and where it can sometimes be a little confusing whether a name in a pattern is a constructor or a variable binding.
|
|
#
?
Aug 6, 2015 09:07
|
|
|
Beamed posted:You're right, it is inherently superior. Having been working half of my life typing code in lines of a maximum of 72 columns, using a horrible 3270 emulation font, I tend to favour a compact notation rather than an expanded one. When you get to the point in which a qualified field name takes half of a line real state you start to appreciate the few characters you get using something like camelCase, even when the language is not case sensitive (in my case, PL/I). Speaking of that, some time ago I found this looking for a code hot spot: code:
|
|
#
?
Aug 6, 2015 10:04
|
|
|
None of this would be a problem if we all used snake_case and hyphen-case.
|
|
#
?
Aug 6, 2015 16:21
|
|
|
|
| # ? May 16, 2024 19:24 |
|
|
NihilCredo posted:Tangentially related: why are most languages still case sensitive? NihilCredo posted:That's a great example, which makes a pretty good argument indeed! It just happens to be an argument for case insensitivity. Is "preventing errors" the only argument? Given that most languages are case sensitive today, what benefit would be gained from making them case insensitive aside from that one? Edit: NihilCredo posted:Has "String string" ever been anything but a code smell? ExcessBLarg! fucked around with this message at 18:56 on Aug 6, 2015 |
|
#
?
Aug 6, 2015 18:34
|
|