This question already has answers here:
When should I use semicolons in SQL Server?
(13 answers)
Closed 8 years ago.
Hello People more knowledgeable than me,
I'm taking some online courses for SQL and I am curious about something. With some instructors they draft script and don't seem to be concerned about ending simple commands with a ; however, other instructors seem to religiously add the semicolon at all times.
I'm just wondering, how important is the semicolon, should it be something that is always part of your script or does it not matter?
I know it's a pretty simple question, but the intro classes don't really define exactly why it's needed and since I'm seeing it used differently... I just want to make sure I understand.
Thank you!
Terminating semi-colons will be required in some future version of SQL Server.
Although it's not currently required, it's not a bad habit to get into.
As far as I know, I neglect semi-colons all too much, and my scripts nearly never break. So my best guess is no.
Still makes the code more readable since you do add a layer of seperation in your code.
Oh, you must use them at CTEs though which aren't first in batch
Related
According to this comment from the general question Is it possible to create a quine in every turing-complete language? it seems like it is said that it's possible.
However I didn't find any Ook! Quine on the internet.
Do you think that it's really possible?
And if yes will we be able to find it?
It wouldn't even be very difficult. You would want to code it in brainfuck and then translate, and the internal representation for each command should be a pair of numbers (probably from 0-2) to represent the punctuation of each half-command. You could borrow much of the structure from Erik Bosman's brainfuck quine.
Updated: here. https://gist.github.com/danielcristofani/1fe53487df1f7afcb5b91c06d95184b2
This is ~40 commands taken directly from Erik Bosman's quine, another ~120 freshly written commands of rather clunky output code to handle Ook!'s verbosity, and then the data segment to represent all that.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
NetBeans 7.4 beta is currently available for public download, and it introduces a weird warning rule by default:
Method length is 16 lines (10 allowed)
My question is: Is this an accepted code convention rule, that can be proven somehow, somewhere ? NetBeans support/devs say it's not a bug, but don't give a statement why they only allow 10 lines, and where exactly this rule has its origin.
You can change the maximum method/function length warning behavior in NetBeans options (it's under Tools->Options->Editor, in the Hints tab, under "Too Many Lines" section in the checkboxes list).
There you can set the maximum number of lines, how you would like to be warned, etc.
I believe that the rule was introduced by NetBeans developers because when working in teams, the automated tools that QAs use to "inspect" code flag long method declarations/functions bodies. Unfortunately, the use of automated tools by "code analysts" is on the rise, whilst their understanding of the reasons behind that are still limited. I do not say that your functions should be hundreds of lines long - that's just plain wrong, but a hard-coded number as a coding law - come on!
The "10 lines rule" has to do with enforcing test-driven development. The theory is that any method that has more than ten lines can be better broken down into units that are testable. it holds up in theory, but in practice a warning like this is more annoying than helpful.
I think there is not a convention about that, and it's very hard to make small functions in particular working in big projects.
I feel that the problem in NetBeans (or the rule) is counting lines with just one bracket or documentation.
This article gives him opinion about write functions with 5-15 lines.
I always disable this warning, as well as the warning about too many nested blocks. I understand the idea around not having large methods but a LOT of the time it's just not practical, and as someone else mentioned if you keep splitting your code into arbitrary functions just to appease the IDE you end up with spaghetti code jumping all over the place, refactoring becomes a huge problem later on as well.
Same as the line length limit warning, maybe a line 50 characters long made you scroll sideways in 1985, but today we have larger monitors (in color now as well!). I've seen people mutilate a line of code by shortening variable names so that it fits within the limit, turning a perfectly readable line of code into an indecipherable mess just so it fits within the limit.
Personally I think those three rules together have caused more garbage spaghetti code than helped create readable / testable code.
I think there is no such rule. I always thought a good convention would be no more lines of code in a class than one can read without scrolling. 10 lines seems not very much for me but in general it's for overview purposes and easier testing..
i have been working on a perl program to process large amounts of dna. It outputs exactly what i need however it takes much longer than i would like using NYTprof i have narrowed down the major problem areas to be the loop that adds my values together. would using inline::C to do the math make my program faster or should i accept the speed and move on? is there another way to improve the speed? here is my program and an input it would run as well as an executable with the default values entered already.
It's unlikely you'll get useful help here (this included). I can see various problems with your code, and none have to do with the choice of language.
use CPAN. If you're parsing genbank, then use some an appropriate module.
You're writing assembly in Perl, and neither Perl nor you are very good at that. It's near impossible to know what's going on when you don't pass parameters to subroutines, instead relying on globals all over the place. What do #X1, #X2, #Y1, #Y2 mean?
The following might be your problem: until ($ender - $starter > $tlength) { (line 153). According to your test case, these start by being 103, 1, and 200, and it's not clear when or if they change. Depending on what's in #te, it might or might not ever get out of the loop; I just can't tell from your code.
It would help if we knew, exactly, what are the parameters to add, the in-out invariants, and what it is returning.
That's all I got.
I second the recommendation of PDL made in a comment, if it's applicable. Or the use of a CPAN module tailored to your problem (again, if applicable).
I didn't see anything that looked unambiguously like "the loop that adds my values together" in that code; please, show just the code you are considering optimizing, ideally with just enough structure around it to actually run it.
So to answer your generic question generically, yes, Inline::C can be a useful tool for optimization if you are certain your performance problem is limited to what it actually can do for you. In using it, be aware that invoking your C code from Perl or vice versa is non-trivially expensive, so you have to have enough code translated to C to minimize the transitions.
I know I risk asking a speculative question, however, inspired by this recent question I wonder which editor does the best job of syntax highlighting Perl. Being well aware of the difficulties (impossibilities) of parsing Perl I know there will not be a perfect case. Still I wonder if there is a clear leader in faithful representation.
N.B. I use gedit and it works fine, but with known issues.
Komodo Edit does a good job and also scans your modules (including those installed via CPAN) and does well at generating autocomplete data for them.
I'm a loyal vim user and rarely encounter anything odd with the native syntax.vim, except for these cases (I'll edit in more if/when I find them; others please feel free also):
!!expression is better written !!!!expression (everything after two ! is rendered as a comment quoted string; four ! brings everything back to normal)
m## or s### renders everything after the # as a comment; I usually use {} as a delimiter when avoiding / for leaning toothpick syndrome
some edge cases for $hash{key} where key is not a simple alphanumeric string - although it's safer to enclose such key names in '' anyway so as to not have to look up the exact cases for when a bareword is treated as a key name
I haven't used it, but Padre should be good since it's written in Perl. IIRC It uses PPI for parsing
jEdit...with the tweaks that I have amassed over the years. It's got the most customizable syntax highlighting I've ever seen.
I use Emacs in CPerl mode. I think it does a terrific job, although similar to Ether's answer, it's not perfect. What's more, I usually use Htmlize to publish highlighted code to the web. It's kind of annoying to use fancier forums like this one that do their own syntax highlighting, since it's not really any easier and the results aren't as good.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
How do I implement dispatch tables in Perl?
I have a hash table that contains commands such as int(rand()) etc.
How do I execute those commands?
You can use eval($str) to execute Perl code you store in a string variable, $str. You could alternatively store your code as function references within a hash, so something like:
$hash{'random'} = sub { int(rand()) };
This way, you could write $hash{'random'}->() to execute the function whenever you want a random value.
See also Implementing Dispatch Tables on PerlMonks.
As other have said, you can execute them using eval. However, please note that executing arbitrary strings of possibly tainted origin via eval is a major security hole, as well as prone to be slow if performance of your application matters.
You can use the Safe module to remove the security hole (not sure how bulletproof that is but much better than naked eval), but performance issues will always be there as Perl will have to compile your code prior to executing it WHILE executing the main program.