|
Yes, in fact - I haven't confirmed - but it looks like the exact model I've been using for years.
It is, quite literally, plug and play. I never have to think about it. Which is exactly what you want for a dock like this.
Back when I was using it with Windows 7, they had driver updates on a fairly regular basis, which was starting to be slightly annoying, especially if you like to keep on top of that. Since moving to 10, I haven't had a single driver update nag, and it "just works".
I've never had other docks so can't do a comparison, but based on my own experience, I'd recommend it in a heartbeat.
|
|
|
|
|
We had someone try this - doesn't work with the Surface Pro.
|
|
|
|
|
thanks for the great info!
diligent hands rule....
|
|
|
|
|
I've been using this with 2 different Surface Pros for several years - since the USB-C version of the Plugable first came out. No issues, though I don't run the monitor off it. I use the DisplayPort port for that
|
|
|
|
|
|
ok it's not really a poll, I dunno how to do the poll thing...
but there is this manager at work, he is always like, there is a method which has only one single internal (to the method variable) and he is like, could your rename you variable abcd to abcdefGhijkLmno?
For me I just found long variable names flat out more painful (it has been 25 years programming, I doubt you will convince me that long variable name are better for me now - and be extension everyone), I assume with all the useless comment I get, the majority also like longVariableNameInTheirMethod. However for me it just confuse me. But who care, code is done, I can obfuscate it if it's what one reviewer wants.
But then this idea just struck me! I could make a poll here and could finally know if I am in the minority, as I suspect, or it's 50/50 or in fact in the majority?
So?
is it ok to have method that only have one variable, call it x? or mySingleVariable? or myVariableType? or mvType?
multiple responses apply (in case you are comfortable with multiple syntax!)
modified 1-Mar-22 20:19pm.
|
|
|
|
|
I usually keep the names of local variables short, using even single-letter names for loop variables, whereas names that appear outside a function are much more descriptive. If someone can't remember what a short name refers to within a function, the problem is either that the function is too long (in which case a longer name is appropriate) or that the reader has dementia.
Either this manager has dementia or knows little about programming but wants to "contribute" by always adhering to the hackneyed rule about making variable names long and descriptive.
|
|
|
|
|
If the variable's purpose is not obvious I try to give it a more explanatory name and those can get long on occasion but I try to avoid long names because I find they can tend to obscure one's logic.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Variables need to be no longer than necessary to indicate what they do.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Super Lloyd wrote: is it ok to have method that only have one variable, call it x? or mySingleVariable? or myVariableType? or mvType?
Of course x. It will (clearly) show that it is just a local thingy that is not important in the grand scheme of things.
andDontUseCamelCaseIfPossible
Mircea
|
|
|
|
|
Loving it! 
|
|
|
|
|
good name length depends on scope size.
it doesn't make any sense to have a 10-char name for a variable that lives for three lines only.
always use a descriptive name that holds the most relevant information, preferably a noun (or adjective)
exceptions: single letter is OK for small loop index, or coordinates (x,y) or EventArgs or when implementing some mathematical/physical formula with strict naming conventions
avoid names that can't be pronounced
avoid names that sound alike
avoid names that are the same except for their casing (exception: property and its backing variable)
avoid confusion, don't have two names that differ only in one char when that would be i/l/1 or o/0
use camelCase for compound names, avoid underscores.
conclusion: abcd is not OK, and abcdefGhijkLmno is worse; and mySingleVariable is not OK.
Luc Pattyn [My Articles]
The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
|
|
|
|
|
out of curiosity I checked some random sample of your code....
(LP#TrayIconBuster)
ToolBarButton64 tbb64=new ToolBarButton64();
ToolBarButton32 tbb32=new ToolBarButton32();
TrayData td=new TrayData();
I think there is a misunderstanding here, you name your variables just as I do! 
|
|
|
|
|
true.
however that's not how I would do it today.
I keep learning and improving my practices.
Luc Pattyn [My Articles]
The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
|
|
|
|
|
Luc Pattyn wrote: avoid names that can't be pronounced
That's a very subjective thing. I know a few words, including my last name, that none of my teachers in America ever came close to say without ending up with a knot in their tongues.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I'll reformulate: always use names that can be pronounced easily.
And yes, all statements that hold adjectives are subjective, including this one. Humans have learnt to deal with that, machines are still struggling.
Luc Pattyn [My Articles]
The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
|
|
|
|
|
I go for as short as possible without doing myself or anyone else a disservice in terms of retaining the intent of a variable or function name. As early as yesterday I have to break down and get wordy with a function name because there seemed no other way. It kinda felt dirty but it is what it is. RestoreFocusAndSelect()
O and I never abbreviate. I've looked at old code of mine and saw oh, ctrlbindrv and thought how coy. 
|
|
|
|
|
Managers aren't allowed to look at my code. The team lead and other devs can of course, but if you try to micromanage me, you may as well expect my resignation EOB.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Yeah! Way to go!
|
|
|
|
|
I learned early on in this business that it pays to be hard nosed about certain things, both for my own sanity, and the good of who I work for.
I also learned to get out early when things looked like they would set me up for failure.
When I interview for a position, I'm the one do the interviewing, because I'm very selective about what kind of shop I'll work for.
I learned that not only can I afford to do this, I can't afford not to, because honestly? There are more bad dev shops out there than good ones, and I have a reputation and my own personal standards to live up to. I will not work for a shop that drags me down due to bad practices and/or bad management.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I am used to far more abstract ways to access data, like directly using hexadecimal memory addresses. That makes me very unobsessed with naming in general. And there are far too many masters of the obvious who name things after, well, obvious or easy to find out things instead of using the variable name to hint at the intention behind a variable.
Anyway, I usually prefer the shorter version. Calling a variable 'ConnectionString' is more than enough. 'ZeroTerminatedArrayOfCharactersWithConnectionInformationForTheApplicationButNotForTheSeparateDatabaseWithUserInformation' might be a little too unwieldy, especially when everything is named like this. And I have seen people go overboard like that. Even with two monitors you can't even read a short line without scrolling.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Variable/Method names should be
descriptive enough to know what it should be
Distinguishable enough from other variables
clear and easy to use
So I'd prefer short names, but if a long name is more appropriate, just do it.
also:
They always taught me : if it's not broken, don't fix it.
Making changes for the sake of changes is never a good idea and I can't imagine a style guideline: "your names should be at least 15 characters long" 
|
|
|
|
|
With exception of loops (and other places like x,y,z where there are conventions) I use descriptive names. I find it easier to maintain long term. "But who cares, the code is done" sounds very strange to me - but then I only work on products that goes on for many years (decades) so it's our own foot we are shooting. I have indeed seen a (understandable) change in attitude from people working on single projects where it is just about what is delivered now, not what you can maintain next year.
If a variable ends up with a long name, it means it is hard to explain what it is doing... which is exactly the case where you need the long name.
|
|
|
|
|
|
kmoorevs wrote: As an aside, do you name your UI controls intelligently, or is Textbox1, Textbox2 good enough?
Doing WPF UI this question is not very relevant.. 
If I were to give a name to UI Element, as it occasionally happen, it usually a short descriptive one
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
