readability

Why should I capitalize my SQL keywords? [duplicate]

由 落花浮王杯 提交于 2019-11-26 18:10:02
问题 This question already has answers here : Closed 7 years ago . Possible Duplicate: Is there a good reason to use upper case for T-SQL keywords? Simple question. I personally find a string of lowercase characters to be more readable than a string of uppercase characters. Is some old/popular flavor of SQL case-sensitive or something? For reference: select this.Column1, case when this.Column2 is null then 0 else this.Column2 end from dbo.SomeTable this inner join dbo.AnotherTable another on this

StringBuilder/StringBuffer vs. “+” Operator

由 独自空忆成欢 提交于 2019-11-26 17:35:46
I'm reading " Better, Faster, Lighter Java " (by Bruce Tate and Justin Gehtland) and am familiar with the readability requirements in agile type teams, such as what Robert Martin discusses in his clean coding books. On the team I'm on now, I've been told explicitly not to use the + operator because it creates extra (and unnecessary) string objects during runtime. But this article , Written back in '04 talks about how object allocation is about 10 machine instructions. (essentially free) It also talks about how the GC also helps to reduce costs in this environment. What is the actual

New (std::nothrow) vs. New within a try/catch block

由 痴心易碎 提交于 2019-11-26 13:48:53
问题 I did some research after learning new , unlike malloc() which I am used to, does not return NULL for failed allocations, and found there are two distinct ways of checking whether new had succeeded or not. Those two ways are: try { ptr = new int[1024]; } catch(std::bad_alloc& exc) { assert(); }; and ptr = new (std::nothrow) int[1024]; if(ptr == NULL) assert(); I believe the two ways accomplish the same goal, (correct me if I am wrong of course!), so my question is this: which is the better

Should java try blocks be scoped as tightly as possible?

由 巧了我就是萌 提交于 2019-11-26 12:06:33
问题 I\'ve been told that there is some overhead in using the Java try-catch mechanism. So, while it is necessary to put methods that throw checked exception within a try block to handle the possible exception, it is good practice performance-wise to limit the size of the try block to contain only those operations that could throw exceptions. I\'m not so sure that this is a sensible conclusion. Consider the two implementations below of a function that processes a specified text file. Even if it is

`if key in dict` vs. `try/except` - which is more readable idiom?

由 孤街浪徒 提交于 2019-11-26 09:26:35
问题 I have a question about idioms and readability, and there seems to be a clash of Python philosophies for this particular case: I want to build dictionary A from dictionary B. If a specific key does not exist in B, then do nothing and continue on. Which way is better? try: A[\"blah\"] = B[\"blah\"] except KeyError: pass or if \"blah\" in B: A[\"blah\"] = B[\"blah\"] \"Do and ask for forgiveness\" vs. \"simplicity and explicitness\". Which is better and why? 回答1: Exceptions are not conditionals

Should a developer aim for readability or performance first? [closed]

由 一个人想着一个人 提交于 2019-11-26 09:00:03
问题 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 6 years ago . Oftentimes a developer will be faced with a choice between two possible ways to solve a problem -- one that is idiomatic and readable,

Is while (true) with break bad programming practice?

由 本小妞迷上赌 提交于 2019-11-26 08:56:02
问题 I often use this code pattern: while(true) { //do something if(<some condition>) { break; } } Another programmer told me that this was bad practice and that I should replace it with the more standard: while(!<some condition>) { //do something } His reasoning was that you could \"forget the break\" too easily and have an endless loop. I told him that in the second example you could just as easily put in a condition which never returned true and so just as easily have an endless loop, so both

Calling getters on an object vs. storing it as a local variable (memory footprint, performance)

由 你说的曾经没有我的故事 提交于 2019-11-26 08:08:56
问题 In the following piece of code we make a call listType.getDescription() twice: for (ListType listType: this.listTypeManager.getSelectableListTypes()) { if (listType.getDescription() != null) { children.add(new SelectItem( listType.getId() , listType.getDescription())); } } I would tend to refactor the code to use a single variable: for (ListType listType: this.listTypeManager.getSelectableListTypes()) { String description = listType.getDescription(); if (description != null) { children.add

StringBuilder/StringBuffer vs. “+” Operator

由 限于喜欢 提交于 2019-11-26 05:29:32
问题 I\'m reading \" Better, Faster, Lighter Java \" (by Bruce Tate and Justin Gehtland) and am familiar with the readability requirements in agile type teams, such as what Robert Martin discusses in his clean coding books. On the team I\'m on now, I\'ve been told explicitly not to use the + operator because it creates extra (and unnecessary) string objects during runtime. But this article, Written back in \'04 talks about how object allocation is about 10 machine instructions. (essentially free)

How to split a long regular expression into multiple lines in JavaScript?

由 巧了我就是萌 提交于 2019-11-26 04:18:04
问题 I have a very long regular expression, which I wish to split into multiple lines in my JavaScript code to keep each line length 80 characters according to JSLint rules. It\'s just better for reading, I think. Here\'s pattern sample: var pattern = /^(([^<>()[\\]\\\\.,;:\\s@\\\"]+(\\.[^<>()[\\]\\\\.,;:\\s@\\\"]+)*)|(\\\".+\\\"))@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\])|(([a-zA-Z\\-0-9]+\\.)+[a-zA-Z]{2,}))$/; 回答1: You could convert it to a string and create the expression by
订阅 readability