- No sense of the depth of the discipline of software engineering
- Shallow knowledge but deep overconfidence
- Wastes energy in disputes about the cosmetics of software engineering
irrelevant, I'm already an expert
Photo by Aleksey Boev on Unsplash
Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account and AddressParser.
Avoid words like Manager, Processor, Data, or Info in the name of a class.
🤔
/**
* Class summarizing user interest data
*/
data class UserData(
val bookmarkedNewsResources: Set<String>,
val viewedNewsResources: Set<String>,
val followedTopics: Set<String>,
val themeBrand: ThemeBrand,
val darkThemeConfig: DarkThemeConfig,
val useDynamicColor: Boolean,
val shouldHideOnboarding: Boolean,
)
data class AmpLinkInfo(
val ampLink: String,
val destinationUrl: String? = null,
)
Why not use tuples?
package com.squareup.moshi.kotlin.codegen.ksp
private class JsonClassSymbolProcessor(
environment: SymbolProcessorEnvironment,
) : SymbolProcessor {
override fun process(resolver: Resolver): List<KSAnnotated> {
val generatedAnnotation = generatedOption?.let {
AnnotationSpec.builder(ClassName.bestGuess(it))
.addMember("value = [%S]", JsonClassSymbolProcessor::class.java.canonicalName)
.addMember("comments = %S", "https://github.com/square/moshi")
.build()
}
}
internal class OfflineFirstTopicsRepository @Inject constructor(
private val topicDao: TopicDao,
private val network: NiaNetworkDataSource,
) : TopicsRepository {
internal class OfflineFirstNewsRepository @Inject constructor(
private val niaPreferencesDataSource: NiaPreferencesDataSource,
private val newsResourceDao: NewsResourceDao,
private val topicDao: TopicDao,
private val network: NiaNetworkDataSource,
private val notifier: Notifier,
) : NewsRepository {
internal class OfflineFirstTopicsManager @Inject constructor(
private val topicDao: TopicDao,
private val network: NiaNetworkDataSource,
) : TopicsRepository {
internal class OfflineFirstNewsManager @Inject constructor(
private val niaPreferencesDataSource: NiaPreferencesDataSource,
private val newsResourceDao: NewsResourceDao,
private val topicDao: TopicDao,
private val network: NiaNetworkDataSource,
private val notifier: Notifier,
) : NewsRepository {
ForbiddenClassName:
active: true
forbiddenName: [".*Manager"]
class ForbiddenNameDetector : Detector(), SourceCodeScanner {
override fun getApplicableUastTypes(): List<Class<out UElement>> {
return listOf(UClass::class.java)
}
override fun createUastHandler(context: JavaContext): UElementHandler? {
if (isKotlin(context.psiFile?.language)) return null
return object : UElementHandler() {
override fun visitClass(node: UClass) {
val matches = forbidden.filter { it.pattern.matches(node.name) }
for (match in matches) {
context.report(
ISSUE,
context.getLocation(node),
"Name ${node.name} is forbidden for ${match.reason}"
)
}
}
}
}
Executors.newSingleThreadExecutor().asCoroutineDispatcher()
// User.kt
data class User(
val firstName: String,
val lastName: String,
val id: Long
)
// Users.kt
fun User.toLoggableString() = TODO()
// Gold.kt
data class Gold(
val amount: Int,
)
// Golds.kt
fun Gold.toSilver() = amount * 1000
// FauxPas.kt
data class FauxPas(
val context: String,
val action: String
)
❓
/** A spec or type which can be annotated. */
public interface Annotatable {
public val annotations: List<AnnotationSpec>
}
/** A spec which contains documentation. */
public interface Documentable {
public val kdoc: CodeBlock
}
What about something that can have a TypeSpec?
get the garbage bag from under the sink
carry it out to the garage
dump it in the garbage can
fun takeOutGarbage() {
RetrievalStrategyFactory.create(Strategy.WITH_HANDS).retrieve(garbageBag)
Carrier.of(Hand.RIGHT).carryTo(garbageCan)
Dumper.dumpIn(garbageCan)
}
@Composable
private fun SearchTextField(
searchQuery: String,
onSearchQueryChanged: (String) -> Unit,
onSearchTriggered: (String) -> Unit,
) {
val focusRequester = remember { FocusRequester() }
val keyboardController = LocalSoftwareKeyboardController.current
TextField(
modifier = Modifier
.fillMaxWidth()
.padding(16.dp)
.focusRequester(focusRequester)
.onKeyEvent {
if (it.key == Key.Enter) {
onSearchExplicitlyTriggered()
true
} else {
false
}
}
.testTag("searchTextField"),
shape = RoundedCornerShape(32.dp),
value = searchQuery,
keyboardOptions = KeyboardOptions(
imeAction = ImeAction.Search,
),
keyboardActions = KeyboardActions(
onSearch = {
onSearchTriggered()
},
),
maxLines = 1,
singleLine = true,
)
LaunchedEffect(Unit) {
focusRequester.requestFocus()
}
}
obtain
fetch
retrieve
acquire
calculate
generate
There are no solutions, only trade-offs
Thomas Sowell
Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account and AddressParser.
Avoid words like Manager, Processor, Data, or Info in the name of a class.
Getting a good instinct for names is hard. You will have to learn to walk the tightrope between obscurity and verbosity.
Follow the idiomatic names in your language and open source community. For team projects, enforce naming conventions using static analysis to avoid bike-shedding.
At the end of the day, decisions on names are compromises too, so learn to deal with names that aren't perfect.
Debit
Credit
$10,000
$10,000
class PaymentProcessor(private val creditCardServer: CreditCardServer) {
fun processPayment(creditCard: CreditCard, money: Money) {
if (!creditCardServer.isAvailable()) {
throw NotAvailableException()
}
val transaction = creditCardServer.beginTransaction().transaction
val payment = creditCardServer.pay(transaction, creditCard, 500)
if (payment.isOverMaxBalance()) {
throw OverMaxBalanceException()
}
}
}
fun testCreditCardIsCharged() {
val paymentProcessor = PaymentProcessor(mockCreditCardServer)
whenever(mockCreditCardServer.isServerAvailable()).thenReturn(true)
whenever(mockCreditCardServer.beginTransaction()).thenReturn(mockTransactionManager)
whenever(mockTransactionManager.getTransaction()).thenReturn(transaction)
whenever(mockCreditCardServer.pay(transaction, creditCard, 500)).thenReturn(mockPayment)
whenever(mockPayment.isOverMaxBalance()).thenReturn(false)
paymentProcessor.processPayment(creditCard, Money.dollars(500))
verify(mockCreditCardServer).pay(transaction, creditCard, 500)
}
class HappyBirthdayViewModel(
private val userRepository: UserRepository
private val clock: Clock
) {
init {
val birthday = userRepository.user.getField("brthiday")
if (birthday == clock.today()) {
_viewState = _viewState.copy(party = true)
}
}
}
fun testBirthday() {
val user = mock()
whenever(userRepository.user).thenReturn(user)
val viewModel = HappyBirthdayViewModel(userRepository)
verify(user).getField("birthday")
}
fun testCreditCardIsCharged() {
val paymentProcessor = PaymentProcessor(mockCreditCardServer)
whenever(mockCreditCardServer.isServerAvailable()).thenReturn(true)
whenever(mockCreditCardServer.beginTransaction()).thenReturn(mockTransactionManager)
whenever(mockTransactionManager.getTransaction()).thenReturn(transaction)
whenever(mockCreditCardServer.pay(transaction, creditCard, 500)).thenReturn(mockPayment)
whenever(mockPayment.isOverMaxBalance()).thenReturn(false)
paymentProcessor.processPayment(creditCard, Money.dollars(500))
verify(mockCreditCardServer).pay(transaction, creditCard, 500)
}
fun testCreditCardIsCharged() {
paymentProcessor = PaymentProcessor(fakeCreditCardServer)
paymentProcessor.processPayment(creditCard, Money.dollars(500))
assertEquals(500, fakeCreditCardServer.getMostRecentCharge(creditCard))
}
replace just this with an in-memory database
applicability
fidelity
brittle
complex
Photo by Markus Spiske on Unsplash
Premature optimization is the root of all evil
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified
Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974
Photo by Edho Pratama on Unsplash
Dangerous minds: How we're getting developer education wrong
By David Rawson
Dangerous minds: How we're getting developer education wrong
- 42