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 4 years ago.
Improve this question
I've just written this:
ldb.Update(emp.Code,emp.number, "text", String.Empty, "EMP", emp.scheme, emp.status, emp.tod, emp.timestamp, emp.Code, emp.oldfrmd)
Its far to wide! How can I shorten this method call? The problem is this isn't my method, so I can't edit it.
It depends on what your concern is:
Too many parameters? Can't really change that without changing the method, although you could introduce a proxying method containing fewer parameters, where each parameter may map to several of the original ones. It looks like you might want to make this a method on whatever the type of emp is, but it's hard to know without more information.
Just too wide on the screen? Use line continuations:
ldb.Update(emp.Code, emp.number, "text", String.Empty, "EMP", _
emp.scheme, emp.status, emp.tod, emp.timestamp, _
emp.Code, emp.oldfrmd)
(IIRC the "_" isn't actually needed in VB10.)
Too many characters? Introduce some local variables, potentially, shortening the eventual call to something like:
ldb.Update(code, number, "text", "", "EMP", scheme, status, _
tod, timestamp, code, oldfrmd)
(Although your overall code will be bigger, of course.)
Since you can't change the method signature, you must really be passing all those fields of emp into it. I would tend to write my own function (pardon my terribly rusty VB; I'm sure there's something wrong with this):
updateLdb(Employee e)
which simply called ldb's function and did nothing more. Using a single letter for a variable name is generally a bad idea, but in this case it saves your line 16 characters, and in a one-line function, "e" isn't particularly less informative than "emp". As Jon says if you move this function into the Employee class, you can get rid of another 16 characters - and it does appear to really belong there.
I would not use "e" as a variable or parameter name in any function that is longer than one or two lines, but in that small a scope, I think you can get away with it without significantly sacrificing readability.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
I'm studying Fortran from the book of Stephen Chapman "Fortran for Scientists and Engineers" (2018).
In page 134, the author wrote this:
Good Programming Practice:
Do not use DO WHILE loops in new programs. Use the more general while loop instead.
This sentence is puzzling me a lot. Is DO-WHILE an unwanted practice? I often find DO-WHILE neater to work with. Is there any disadvantage of using DO-WHILE in terms of speed?
DO-WHILE
INTEGER :: i = -1
DO WHILE (i < 0)
PRINT *, 'Enter a non-negative number:'
READ(*,*) i
END DO
General while loop:
INTEGER :: i = -1
DO
PRINT *, 'Enter a non-negative number:'
READ(*,*) i
IF (i >= 0) EXIT
END DO
Is there any disadvantage of using DO-WHILE in terms of speed?
No. There is no general reason why do while would be slower than do. A decent optimising compiler should always be able to convert a do while loop into the equivalent do loop (although not always vice-versa). Of course, if you are interested in performance in a specific case then you should try both and profile the code rather than relying on generalities.
Is DO-WHILE an unwanted practice?
No. If a do while loop is the clearest way of expressing your code, use a do while loop.
The argument "X is more general than Y, so always use X instead of Y" is clearly a fallacious over-generalisation. A GOTO is more general than a do loop, but you certainly shouldn't be replacing your do loops with GOTOs.
I can read from this book, just before the citation you give :
This construct is a special case of the more general while loop, in which the exit test must always occur at the top of the loop. There is no reason to ever use it, since the general while loop does the same job with more flexibility.
These are mostly facts, except "There is no reason to ever use it", which is just the personal opinion of the author. And anyway "there is no reason to use it" is not the same as "there are reasons to never use it" (as far as I know there are no such reasons).
That said, as a matter of style, in the particular example you give, the do while construct is not the best choice IMO, as it forces you to (artificially) initialize i before the loop. The initialization is not needed with the general do loop.
EDIT : as mentioned in the comments the initialization is actually still needed. But this is because of the READ(*,*) that does not garantee i to be assigned. Such a read should be protected against possible input errors, but this a different topic...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
As far I as my experience tells me, boolean variables usually named in format - is/has+noun/adj/verb, e.g isValid, isButton, hasClickedLink
But say there is the case where we have some flag which straightly tells whether to do something, like for example, clean to indicate that cleanup function should be automatically called in the end.
How to name such a booleans? Same clean - is ambiguous, looks like a method name more, but naming it toClean is, I don't know, too weird. Or should I name it like callCleanup?
Thanks in advance!
In this case i usually append the word wanted, which makes cleanWanted. In general, for boolean variables I also prefer to always let the last word be an adjective. This makes it very clear that it represents a truth value. The is/has prefix is often superfluous, as in hasClickedLink which is more concisely communicated with linkClicked.
methods are usually one word adjectives with a capitol at the start
maybe create a method that sets the flag
for example
void Clean(){
clean = True;
}
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I tried to make a custom record type in order to store information of a product and call it in functions and procedures when needed. The code is written in a script compiler of a Delphi based ERP program. The problem I'm facing is that I get a syntax error on the record type definition when I execute the script.
I searched the internet for an hour or so, but wasn't able to find a solution. My script is as next:
Unit Paneelwand;
interface
Uses System, Classes, DB, SysUtils, Graphics, Types;
type
TPanel = record
Ref, PType : string;
Width, Heigth, Thickness, PriceSheets, PriceBitum, PriceHardboard, PricePermmFrameWidth, PricePermmFrameHeigth : float;
end;
implementation
//rest of the code
The syntax Error is on line 6 "TPanel = record". I can't find what I did wrong. Please, help?
By the way: the script is saved as a .psc file and referenced to in another script with its filename as a reference in the uses section. This works fine with other scripts I wrote. I also never had to add a unit line as the scripts are called by the file names.
I updated the script, by deleting the part that is not part of the problem and added the changes that were suggested below by the great people that try to help me. However, the error remains on the same line --> 'TPanel = record;'.
"Type" is reserved word. try other word
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 months ago.
Improve this question
[disclosure: I asked about this earlier on the NixOS channel but didn't get an answer after 30 minutes and it's a busy channel. If I get one there, I'll replicate it here]
I'm trying to add some lines to a configuration file in NixOS (for example /etc/pam.d/sudo). The configuration options available in pam.nix do not include the line I want to add (in this case, account requisite pam_time.so), and it does not include an extraConfig option either.
I know I can create new configuration files using environement.etc.filename.text so I went with that, but sudo nixos-rebuild switch then complains that it has two sources for the configuration file, the official one and mine (mismatched duplicate entry /nix/… <-> /nix/…):
environment.etc."pam.d/sudo".text = ''blah'';
Is there a general way to append to a /etc/ configuration file (or to patch it) in NixOS?
Or is the only way to modify the system .nix files (e.g. modifying pam.nix, which I'm reluctant to do as it will collide with future updates)?
You can add lines to the default value of security.pam.services.sudo.text using mkOverride or the shortcut mkDefault to give your value the same priority as the default. You can control the order with mkOrder or the shortcuts mkBefore and mkAfter. So to append, you could do:
security.pam.services.sudo.text = pkgs.lib.mkDefault( pkgs.lib.mkAfter "# hi" );
When there are multiple values for an option, only the values with the lowest priority are kept. If there are still multiple values, they are sorted and merged. mkOverride and mkOrder create special values that the code in modules.nix recognizes when it is doing this. Ordinary values have the default priority (100) and sort order (1000). pam.nix uses mkDefault for the value it creates for the text option, which makes the priority 1000, thus ordinary values will replace it instead of being merged.
The NixOS manual section on Modularity explains a bit more.
I don't think you can do this generically for environment.etc because the target file doesn't have to match the attribute name, and pam.nix in particular does not name any of its entries in environment.etc. It is more like a list of instructions that are processed in sequence. See etc.nix and
make-etc.sh
For the files of /etc/pam.d/sudo and other files in the same directory, a simple solution is to use security.pam.services.sudo.text, but my current best attempt requires hardcoding the original contents of the file.
security.pam.services.sudo.text = ''
existing contents of /etc/pam.d/sudo …
extra lines …
'';
Hopefully other answers will come up with a more general-purpose way of altering configuration files (and keeping their original contents).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Is it considered bad practice to use colons to put two statements on the same line in Visual Basic?
There is nothing inherently wrong with using the colon to combine statements. It really depends on the context but as long as it doesn't reduce readability, there is nothing wrong with it.
As a general rule I avoid using the colon for this purpose. I find it's more readable to have one statement per line. However this is not a colon specific issue. I avoid doing the same with a semi-colon in C# or C++. It's just a personal preference.
It's a good practice in moderation, because sometimes readability is enhanced by concatenating two lines:
when the lines are short and intimately
related
when the lines are short and trivial
Option Compare Database: Option Explicit ''My favorite!
rsDataSet.Close: Set rsDataSet= Nothing
Don't do it if:
it hurts readability.
it complicates debugging. Control structures such as If...Then need to stay clean. You'll be glad you kept it simple when it's time to set a break point.
it compromises future editing. Often you want to keep sections portable. Moving or re-structuring a block of code is easily hindered by attempts to minimize your code.
In general, I'd advise against it, as it makes for busier code.
However, for simple tasks, there is nothing wrong with it. For instance:
for i = 1 to 10: ProcessFoo(i): next
I think a line like this is short enough not to cause confusion.
I'll take the other side. I don't like dense lines of code. It is easier to skim code when lines are not combined.
Combining statements also makes it easier to create long functions that still fit on a single screen.
It isn't a major sin, I just don't like it.
I also don't like one line If statements.
To me you shouldn't say "never do thus", you should just say "If you do this, a possible problem is such and such." Then just weigh the pros and cons for yourself. The pro is brevity/few lines of code. Sometimes this can aid readability. For instance some people use it to do vb.Net declarations:
Dim x As Long: x = 1
Or wait loops:
Do Until IE.ReadyState = READYSTATE_COMPLETE: DoEvents: Loop
But obviously you can really make it rough on someone too:
Public Sub DoYouKnowWhatThisDoes()
MsgBox Example
End Sub
Private Function Example()
Const s$ = "078243185105164060193114247147243200250160004134202029132090174000215255134164128142"
Const w% = 3: Const l% = 42: Dim i%, r$: For i = 1 To l Step w: r = r & ChrW$(Mid$(s, i, w) Xor Mid$(s, i + l, w)): Next: Example = r
End Function
Another practical reason that you might not want to use this approach is breakpoints. Breakpoints can only be set by the line. So if you have several things executing on the same line you can't isolate the second thing. It will stop on the first statement. (This is also one of the reasons some people don't like single line ifs.) It just complicates debugging a little.
I usually don't use colons in production code for this reason. However I do use them to improve the brevity of "copy/paste" code that I post in forums and elsewhere. YMMV:)
I realize this is a very old question, but it was the first result on my Google search, so I hope I can be forgiven for chiming in here.
There is one situation (exactly what led me here in fact) in which this approach is not only useful, it's the only way to accomplish the desired result: the Immediate window. Any code you want to execute in the Immediate window must all be on one line. So in order to use any form of Do, Case, For, While, or With in the Immediate window, you will need to use colons.
It is considered bad practice in most of the sites at which I have worked. And by most of the VB developers with whom I have worked. And in my head. If I see it, I will admit that I would almost certainly change it. I say "almost" because I admit there's a possibility that I could find a piece of code that looked better that way. I don't expect to see it in my lifetime, though.
I also really don't like one-line **If**s either.
Both are most likely hangovers from the days of VGA (640x480) monitors; that's no excuse these days.
I've only ever used it when I'm clsoing a recordset and setting the variable to nothing. I figure one line instead of two gives me more lines of code on the screen and doesn't detract from readability.
I've seen it used in simple select cases such as the following but that would be as far as I would go.
Select Case success
Case ERROR_FILE_NO_ASSOCIATION: msg = "no association"
Case ERROR_FILE_NOT_FOUND: msg = "file not found"
Case ERROR_PATH_NOT_FOUND: msg = "path not found"
Case ERROR_BAD_FORMAT: msg = "bad format"
from http://vbnet.mvps.org/index.html?code/system/findexecutable.htm
And even then I would've lined up the "msg =" portion.
I've never seen this mentioned in an official capacity at any of the companies which I've worked. But I do think that using colons excessively can start to make your code less readable and more of a pain to maintain.
I do tend to use these myself at times, for example when checking for cancel in one of my recent projects:
If _bCancel Then Status = CancelProcess() : Return Status
Putting this in kept my code readable than the alternative IF block.
But it can be taken too far, I've recently inherited a project which is replete with examples of taking colon usage too far :
Select Case GetStringValue(Index).Trim.ToLower
Case "yes", "y" : GetBooleanValue = True
Case "no", "n" : GetBooleanValue = False
Case Else : GetBooleanValue = Nothing
End Select
Personally I find the above to be a bit much.
I like this one
Using pro As New Process() : With pro
...
End With
End Using
I've seen it used in class declarations when using inheritance or implementing an interface:
Public Class DerivedClass : Inherits BaseClass
...
End Class
But like the others, I also discourage its use.
Chris
The answer to the question is No. Anything beyond No is purely subjective and wasteful irrespective of the answer outside of a simple No. Below is my waste of typing.
Are you some sort of slave? Do as you wish. You are the center of your universe not some stranger from StackOverflow. If you work for a company the question is mute because coding style would already be defined and completely out of your control. As for one's self, who in this universe is going to ever in all eternity look at let along care about your code.
I would choose A over B. As evident this shows the purpose of a colon without the use of a colon. It's to save space. Below saves space and makes code far more readable. Keeps It Simple Stupid. Same for ternary ? : usage. When the code is inherently complex then a colon, single line if then else, or ternary no longer should be considered.
'================================================================
'A
If somevalue1 = 0 Then AddLogTry("True") Else AddLogFalse("False")
If somevalue2 = 0 Then AddLogTry("True") Else AddLogFalse("False")
If somevalue3 = 0 Then AddLogTry("True") Else AddLogFalse("False")
'================================================================
'================================================================
'B
If somevlaue1 = 0 Then
AddLogTrue("True")
Else
AddLogFalse("False")
EndIf
If somevlaue2 = 0 Then
AddLogTrue("True")
Else
AddLogFalse("False")
EndIf
If somevlaue3 = 0 Then
AddLogTrue("True")
Else
AddLogFalse("False")
EndIf
'================================================================