Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Subjunctive posted:

Unicode defines the set of whitespace in each revision, no? Upgrade your libicu and you're done.

God that is weird to think about.

# ? Feb 26, 2016 00:05

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 15:18

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Imagine what weird javascript vulnerabilities would exist if you could set the locale of the parser

# ? Feb 26, 2016 00:08

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

FamDav posted:

That's a p romantic view of mathematics but don't worry it's actually full of bigotry and is hecka anglocentric (and before that it was France and Germany, sometimes Russia but they mostly had their work stolen or ignored).

The idea that math is language-agnostic is pretty hilarious. Translated math papers mostly don't exist, and in the rare cases that they do exist they're full of english (or transliterated english) words because there's no commonly accepted translation for a ton of the jargon.

# ? Feb 26, 2016 00:08

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

MALE SHOEGAZE posted:

Imagine what weird javascript vulnerabilities would exist if you could set the locale of the parser

You can, if I understand what you mean. The parser is locale-agnostic (what would it mean to honour a locale? translated keywords?), but the source decodes as whatever the specified character set is. SHIFT-JIS, EUC-KR, UCS-4, 8859-1, knock yourself out.

# ? Feb 26, 2016 00:13

fritz: Jul 26, 2003

Plorkyeran posted:

Translated math papers mostly don't exist, and in the rare cases that they do exist they're full of english (or transliterated english) words because there's no commonly accepted translation for a ton of the jargon.

Are you sure about that? http://www.ams.org/publications/journals/translation/translation

# ? Feb 26, 2016 00:29

Bonfire Lit: Jul 9, 2008; If you're one of the sinners who caused this please unfriend me now.

ExcessBLarg! posted:

Folks complain that non-ASCII Unicode capitals don't count for this purpose, but the reason is that capitalization and its rules (outside [A-Z]) is language/locale dependent, and they didn't want to go down that path.

But isn't it case folding that's language dependent, not the letter case itself? I.e., if you have an I, you don't know whether the lower case should be i or ı, but at least you can say for certain that it's a capital.

# ? Feb 26, 2016 01:11

Winter Stormer: Oct 17, 2012

fritz posted:

Are you sure about that? http://www.ams.org/publications/journals/translation/translation

I suspect he's talking about papers translated from English into another language.

# ? Feb 26, 2016 01:49

ExcessBLarg!: Sep 1, 2001

Bonfire Lit posted:

But isn't it case folding that's language dependent, not the letter case itself?

You're right, I believe that's actually the case.

Ruby's handling of Unicode came up quite a bit ten years ago on ruby-talk mailing list when m17n support was being planned for Ruby 1.9 (the big breaking changes version equivalent to Python 3); this being one of the threads. Anyways, the original argument was that String#upcase and String#downcase couldn't be reliably implemented in certain locales, one of the examples being yours, and so Ruby itself shouldn't be in the business of inspecting or transforming Unicode codepoints and restrict itself to the ASCII range. I think the behavior of the interpreter was a related matter, or even may be as simple that they wanted Ruby code to function identically for any ASCII-compatible source encoding interpretation.

# ? Feb 26, 2016 02:06

Carbon dioxide: Oct 9, 2012

Related to this discussion: ಠ_ಠ

# ? Feb 26, 2016 07:18

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

int _ಠ; // private eye

Side note: apparently the forums don't like unicode in code blocks.

# ? Feb 26, 2016 15:30

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Subjunctive posted:

Wow that is terrible design. Newlines aren't semantic whitespace? Tab characters? That's trippy poo poo.

Newlines are semantic newlines, and incredibly, I forgot tabs. My ridiculous point stands, there's plenty of space characters you can use in Ruby identifiers.

It also works in Slack names.

# ? Feb 26, 2016 15:56

Soricidus: Oct 21, 2010; freedom-hating statist shill

Doc Hawkins posted:

Newlines are semantic newlines, and incredibly, I forgot tabs. My ridiculous point stands, there's plenty of space characters you can use in Ruby identifiers.

It also works in Slack names.

if i ever have to write ruby, I will construct variable names exclusively from bidi control characters

# ? Feb 26, 2016 18:57

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

Bognar posted:

int _ಠ; // private eye

Side note: apparently the forums don't like unicode in code blocks.

Ha.

# ? Feb 26, 2016 20:25

TheresaJayne: Jul 1, 2011

I have just been introduced to a true horror.

DAL-C coding standards

1) You cannot use Recursion
2) you cannot use if then else you have to use a switch
3) you cannot use ++ and -- you have to do a = a + 1
4) all functions have to return a success status (boolean) so any results have to be passed back as pointers passed in... (how does that make anything more safe and secure)
5) Union is banned (Rule 18.4 (required):Unions shall not be used.)
6) as is floating point

The full horror is here [link]http://caxapa.ru/thumbs/468328/misra-c-2004.pdf[/link]

The most annoying so far is this one

78
Rule 20.4 (required):
Dynamic heap memory allocation shall not be used.
[Unspecified 19; Undefined 91, 92; Implementation 69; Koenig 32]
This precludes the use of the functions
calloc , malloc , realloc and free

There is a whole range of unspecified, undefined and implementation-defined behaviour associated
with dynamic memory allocation, as well as a number of other potential pitfalls. Dynamic heap
memory allocation may lead to memory leaks, data inconsistency, memory exhaustion, non-
deterministic behaviour.
Note that some implementations may use dynamic heap memory allocation to implement other
functions (for example functions in the library
string.h
). If this is the case then these functions
shall also be avoided

TheresaJayne fucked around with this message at 08:24 on Feb 29, 2016

# ? Feb 29, 2016 08:15

raminasi: Jan 25, 2005; a last drink with no ice

What about any of that sounds horrific for critical systems?

# ? Feb 29, 2016 08:25

JawnV6: Jul 4, 2004; So hot ...

TheresaJayne posted:

Dynamic heap memory allocation shall not be used.

Good.

# ? Feb 29, 2016 08:28

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Of course, it becomes a real horror if someone starts using an ad-hoc allocation scheme in a static pool in order to avoid the technical restrictions of "no dynamic memory", while completely defeating the entire point.

# ? Feb 29, 2016 08:29

TheresaJayne: Jul 1, 2011

The main horror is coming from old style C, you have to create arrays at start time and use a predefined slot in the array and then track which slot you are using.

Its worse than trying to remember what is on the stack in Forth

# ? Feb 29, 2016 08:36

vOv: Feb 8, 2014

Plus I'm not seeing where it says you have to use switch instead of if/else-if/else chains. Or where every function has to return a boolean.

# ? Feb 29, 2016 08:37

TheresaJayne: Jul 1, 2011

vOv posted:

Plus I'm not seeing where it says you have to use switch instead of if/else-if/else chains. Or where every function has to return a boolean.

Thats local changes being enforced by the client (Space and Defence ) on the project i am on - above and beyond the misra standards

# ? Feb 29, 2016 08:40

Soricidus: Oct 21, 2010; freedom-hating statist shill

TheresaJayne posted:

5) Union is banned (Rule 18.4 (required):Unions shall not be used.)

loving republicans

# ? Feb 29, 2016 09:28

Space Kablooey: May 6, 2009

TheresaJayne posted:

2) you cannot use if then else you have to use a switch

What's the rationale behind this one?

# ? Feb 29, 2016 13:46

Athas: Aug 6, 2007; fuck that joker

HardDisk posted:

What's the rationale behind this one?

Yes, that's also the only one I find confusing.

Banning dynamic allocation is a good thing. It is way overused in much C code. (There are obviously many places where it is necessary, but it is probably good practice to look for alternatives first.)

It is kind of weird to require boolean return values. What about different error codes?

# ? Feb 29, 2016 14:51

TheresaJayne: Jul 1, 2011

HardDisk posted:

What's the rationale behind this one?

It appears that some of the rules i have to follow is based on the misra std but also custom rules made up in the mists of time,

amongst these are

for is not allowed you have to use while do,

if then elseif is not allowed it has to be switch

switch must have a default that throws an error

all functions must return an enum of SUCCESS or FAIL

# ? Feb 29, 2016 16:23

feedmegin: Jul 30, 2008

TheresaJayne posted:

if then elseif is not allowed it has to be switch

This doesn't seem like a win to me. What if you forget a break between two cases and it falls through (into another non-default case)?

# ? Feb 29, 2016 16:54

qntm: Jun 17, 2009

I would honestly expect that rule to be reversed, outlawing switch in favour of if/else.

# ? Feb 29, 2016 16:56

TheresaJayne: Jul 1, 2011

feedmegin posted:

This doesn't seem like a win to me. What if you forget a break between two cases and it falls through (into another non-default case)?

thats another rule each case has to have a break
and you have to explicitly define all returns
as default has to be an exception

# ? Feb 29, 2016 17:08

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

eliminating malloc in safety critical systems is a good thing, since now you can *prove* your program will run in N amount of memory. it eliminates a whole class of errors.

# ? Feb 29, 2016 17:11

feedmegin: Jul 30, 2008

TheresaJayne posted:

thats another rule each case has to have a break
and you have to explicitly define all returns
as default has to be an exception

That's nice, but what if you forget your return (instead of a break, presumably, because then that break would be dead code), and what I said happens? It's adding an explicit extra thing you have to type over an if/else or bad things will happen, and the first you'd know about it is that when thing A is supposed to happen instead A happens then B, at runtime. Like, instead of 'lock up the contact the fighter is investigating' it becomes 'lock up the contact and then immediately shoot a SAM at it' and suddenly Iran Air 655 happens.

Rules like this are supposed to make it harder to slip up, not easier. :shobon:

# ? Feb 29, 2016 17:14

Symbolic Butt: Mar 22, 2009; (_!_); Buglord

TheresaJayne posted:

3) you cannot use ++ and -- you have to do a = a + 1

I'm actually ok with this, hail python.

# ? Feb 29, 2016 17:39

JawnV6: Jul 4, 2004; So hot ...

feedmegin posted:

That's nice, but what if you forget your return (instead of a break, presumably, because then that break would be dead code), and what I said happens?

What part of "every case has to have a break" is ambiguous enough for you to go stuffing returns in there? It's one thing to look at the rules and try to think of clever ways around them, tossing them out entirely then claiming victory seems kinda hollow.

# ? Feb 29, 2016 17:39

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Suspicious Dish posted:

eliminating malloc in safety critical systems is a good thing, since now you can *prove* your program will run in N amount of memory. it eliminates a whole class of errors.

Probably just me being a terrible programmer, but wouldn't this mean that working with lists of, say, structs would be really painful. Like, if I need to make a process table under these rules I'd have to pre-allocate an array of however many at startup and then be stuck with those, yeah? If I only end up needing 3 out of the 64 I allocated in a particular run, I've wasted a lot of memory. If I bump up against the ceiling of 64, I have to write a bunch of code to deal with that.

Or is this all a non-problem because on a system critical enough to have these rigid rules it would be tested and validated to hell and back to prove I need exactly N of these structs and if it's ever not N then something very bad has happened that no error handling can save us from?

# ? Feb 29, 2016 17:45

qntm: Jun 17, 2009

TheresaJayne posted:

if then elseif is not allowed it has to be switch

switch must have a default that throws an error

This is almost starting to make sense. So I guess instead of

C code:

if(test(x, y)) {
    do_this();
} else {
    do_that();
}

You have to do something like

C code:

int z = test(x, y);
switch(z) {
    case 1:
        do_this();
        break;
    case 0:
        do_that();
        break;
    default:
        // something has gone seriously wrong!
        return FAILURE;
}

which protects you from situations where test has been refactored and its range of return values is more numerous than previously thought? I guess?

# ? Feb 29, 2016 17:53

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

LeftistMuslimObama posted:

Probably just me being a terrible programmer, but wouldn't this mean that working with lists of, say, structs would be really painful. Like, if I need to make a process table under these rules I'd have to pre-allocate an array of however many at startup and then be stuck with those, yeah? If I only end up needing 3 out of the 64 I allocated in a particular run, I've wasted a lot of memory. If I bump up against the ceiling of 64, I have to write a bunch of code to deal with that.

Or is this all a non-problem because on a system critical enough to have these rigid rules it would be tested and validated to hell and back to prove I need exactly N of these structs and if it's ever not N then something very bad has happened that no error handling can save us from?

Your first paragraph is what Jabor was talking about with "using an ad-hoc allocation scheme in a static pool in order to avoid the technical restrictions of "no dynamic memory" ... completely defeats the entire point." The idea is, yes, that you should know what your maximum allowed allocations are, and any situation that requires more allocations would be a failure state that needs to be handled elsewhere -- rather than either attempting to allocate more memory and failing, or attempting to read off the end of a statically-allocated block of memory and trampling something. It's not so much that such a state should be guaranteed impossible to happen, as it is that you want to properly recognize that it has happened, rather than trying to blindly allocate the memory and then fail because memory is not actually unlimited, much as we might like to pretend otherwise.

The latter failure state (of writing off the end of an array and trampling memory) is not uncommon in early console videogames (mostly SNES era and earlier), where everything was statically-allocated, but they weren't sufficiently rigorous in ensuring that it was impossible to use more memory than was allotted at the beginning of execution.

# ? Feb 29, 2016 18:01

feedmegin: Jul 30, 2008

JawnV6 posted:

What part of "every case has to have a break" is ambiguous enough for you to go stuffing returns in there? It's one thing to look at the rules and try to think of clever ways around them, tossing them out entirely then claiming victory seems kinda hollow.

So every case end with ''return <foo>; break;'? Fine, I guess.

I'm not trying to talk about people intentionally tossing rules out, it's just that rules like these are supposed to help if you accidentally forget to do something (e.g. like 'always use braces with if and else' so that mis-indented code doesn't get unconditionally executed when you don't expect it to). If someone forgets to write the return/break part of their 'if' case then they are actively worse off than if they use an actual if/else which cannot under any circumstances fall through from the if part, is what I was getting at.

# ? Feb 29, 2016 18:18

JawnV6: Jul 4, 2004; So hot ...

feedmegin posted:

I'm not trying to talk about people intentionally tossing rules out

but thats literally what you're doing

I haven't worked with MISRA for a long time, but returning from a case doesn't smell right. I'm pretty sure there's a variant or full blown rule that enforces single return. So this imagined case where magical vectors are conspiring won't happen. This is a lot of words to talk about a case that a 90's linter could nail with 100% accuracy too.

# ? Feb 29, 2016 18:29

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

LeftistMuslimObama posted:

Probably just me being a terrible programmer, but wouldn't this mean that working with lists of, say, structs would be really painful. Like, if I need to make a process table under these rules I'd have to pre-allocate an array of however many at startup and then be stuck with those, yeah? If I only end up needing 3 out of the 64 I allocated in a particular run, I've wasted a lot of memory. If I bump up against the ceiling of 64, I have to write a bunch of code to deal with that.

Or is this all a non-problem because on a system critical enough to have these rigid rules it would be tested and validated to hell and back to prove I need exactly N of these structs and if it's ever not N then something very bad has happened that no error handling can save us from?

Having worked under these kinds of rules before it's not as bad as you might think. The most important thing is that it forces you to consider the memory you're using and the space complexity of your algorithms, which is kinda the point I guess.

# ? Feb 29, 2016 18:57

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

HappyHippo posted:

Having worked under these kinds of rules before it's not as bad as you might think. The most important thing is that it forces you to consider the memory you're using and the space complexity of your algorithms, which is kinda the point I guess.

Makes sense. I work almost exclusively in managed languages for work so I don't typically have to think about that stuff quite as hard, but when I worked in C for my college OS course it was definitely something to consider. I had to deal with memory complexity a lot in my algorithms class too, but only in an abstract sense because everything was done on paper in the form of proofs of our algorithms. There was no programming at all.

# ? Feb 29, 2016 19:27

brap: Aug 23, 2004; Grimey Drawer

This may be the worst can of worms to open, but is there any hard evidence that connects the use of multiple return with increased defects?

# ? Feb 29, 2016 21:07

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 15:18

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

fleshweasel posted:

This may be the worst can of worms to open, but is there any hard evidence that connects the use of multiple return with increased defects?

Every argument I've ever heard against it is an appeal to intuition rather than anything based in research. It usually goes along the lines of "just think about it, if there's more than one route to trace through this code it becomes difficult to reason about and you'll make mistakes". To me, this argument usually feels like they think people write rube golderbergesque function with 37 return statements or something, but nearly every case of multiple return I've seen is typically the actual end of the function, and then two or three spots where you short-circuit out early if an error is detected so the return code can signal that error without proceeding further into the function. Maybe I just haven't been looking at stupid enough code, though.

edit:
In fact, I crave multiple return in the language our database runs (MUMPS), because in MUMPS you can't return with a value during a nested scope, so for example (the $O in this example is just he mumps b-tree version of a foreach. you can read my posts in the 'pos terrible programmers thread if you crave pain and understanding):

code:


searchroutine(inputArray) n done, err, currentitem
f  s currentitem=$O(inputArray(currentitem)) q:currentitem=""  d  q:done q:err]""
. i inputArray(currentitem)=<some condition> s done=1
. e i <some err condition> s err=<error code>
i err]"" q err
q currentitem

In this example, you need two additional variables to track whether you've completed the search or hit an error during the loop. In real-life code, this can get nasty because loops can get deeply nested or contain a lot of logic. This means you can risk blowing away one error with another within one iteration of the loop (unless you quit inline, which can have its own unintended side effects), and it often means that the actual handling of these variables is really far away from where they're declared and set, meaning it can be hard to discern (both technically and contextually) what they mean at the point that you have to actually do something with their values.

I'd much rather be able to just return with a value at the point I'm setting those variables. It makes it very clear that the loop/function is done at the success point, and it makes it clear where in the loop an error occurred and that this error results in the function terminating and returning an error code. It's annoying to have to read the whole thing to know whether err is something that will get handled internally or get thrown back out to the caller, etc.

The MUMPSorceress fucked around with this message at 21:26 on Feb 29, 2016

# ? Feb 29, 2016 21:11

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »