V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  frodez  ›  全部回复第 1 页 / 共 2 页
回复总数  30
1  2  
2023-03-20 15:50:01 +08:00
回复了 leonard916 创建的主题 Java 目前自用工具库,求 star
其实我提供一个 idea ,就是数字转换成中文的大写金额,这个功能在国内有一定作用,然后没有较为成熟的实现。而且这个转换规则挺复杂的,要实现正确并不简单。
我曾经给公司撸了一个,但离开公司的时候没有带出来。
2022-12-05 18:57:46 +08:00
回复了 hongchaodeng 创建的主题 程序员 为什么大家这么讨厌 Electron?
2022-11-15 20:09:28 +08:00
回复了 diandian666 创建的主题 程序员 十年程序员难倒了一个算法上面,真的老了
@diandian666 你看一下 83L 。
2022-10-20 13:53:23 +08:00
回复了 LxnChan 创建的主题 Linux 现在有较为轻量且稳定的 Linux 桌面推荐吗
我个人比较看中对 wayland 的支持,毕竟显示效果比 x11 好很多,所以还是 gnome 吧。
2022-10-19 10:02:47 +08:00
回复了 jatsz2020 创建的主题 Linux 现在最轻量级的 Linux 服务器版本有啥推荐的吗?
debian 不装桌面,在完全无多余后台任务时,空载内存占用就几十 MB 。
2022-10-16 14:50:09 +08:00
回复了 hardwork 创建的主题 程序员 c/c++多线程读写问题,怎么反驳?
先保证逻辑正确,再保证实现正确。逻辑上无法保证偏序关系的,就必须使用同步原语来确保其中关键操作的偏序关系,这是逻辑正确的基本要求,无法取消。
2022-10-04 22:06:33 +08:00
回复了 CrazyCollin 创建的主题 程序员 秋招 gg,想做开源方向可行吗
要是有实习就好了,可惜导师不放实习。
2022-09-16 10:18:57 +08:00
回复了 littlerainer 创建的主题 程序员 适合程序员 or 计算机研究生的轻薄笔记本选择
@FrankHB 我这边情况是,人少的课,且不在老教室上,就好找插座;人多的课,无论是否有插座,都很难赶上,尤其是多节课连轴上的时候几乎不可能赶上;人少的课,如果在没有插座的老教室,那就没办法了。
2022-09-14 11:53:47 +08:00
回复了 littlerainer 创建的主题 程序员 适合程序员 or 计算机研究生的轻薄笔记本选择
@marcong95 研一课多,往往连轴转,而且不容易抢到充电插座,所以经常是一上午 /下午没有充电器。光记笔记还好,万一不喜欢调低亮度,加上需要做些稍微重点的工作(比如编译),一上午 /下午就能把电用完了。
2022-09-13 19:11:04 +08:00
回复了 littlerainer 创建的主题 程序员 适合程序员 or 计算机研究生的轻薄笔记本选择
我推荐战 X ,amd 的驱动开源,不会出问题的。
2022-09-13 19:08:16 +08:00
回复了 littlerainer 创建的主题 程序员 适合程序员 or 计算机研究生的轻薄笔记本选择
@marcong95 你要知道,上课的大教室里充电位置很少的,而且都在边缘不在中间。有些老旧一点的教室甚至没有充电插头。
@pastor 需要,但是是一种更准确的强制措施,因为首先,你不先处理 result 或者 optional (哪怕是直接写上 unwrap )就无法拿到值;其次,反过来看 go 这边,你无法阻止 go 在返回时既返回值也返回 err ,就像楼主代码里的那样。rust 是强制,go 是约定,我是不觉得约定和强制“基本一样”的。
@pastor 但 golang 的问题在于只能约定必须先处理 err ,而无法强制必须处理 err ,相反 rust 哪怕是 unwrap 也是对 err 的处理,虽然不负责任,但至少保证了强制处理 err 。而且 golang 甚至允许既返回值也返回 err 的情况,相反 rust 的 option 和 result 就能根本上避免这个问题。所以 golang 在错误处理这一点上,比起真正先进的语言还有很大差距。
2022-08-07 19:57:33 +08:00
回复了 Konys 创建的主题 Go 编程语言 Java 转 Go
@qianxiaoxiao 轮子的使用得看情况,平时大家考虑得最多的是节约工作量,而往往忽略了共用的轮子兼容性和 bug 一般较少的优点。
我个人建议是双主机,一台装 windows 一台装 linux (如果其中一台是笔记本,那最好是笔记本装 windows )。windows 上玩游戏、进行日常 IM 通信,linux 上开发。windows 机器上也可以安装 ssh/vscode remote 之类工具远程到 linux 机器上。这是最简单最不折腾的方案。
@nebkad 我觉得 @kkocdko 的意思其实是跟着发行版的 LTS 版本节奏走,比如 debian 就用 bullseye 不用 sid ,并且尽量使用桌面环境自带全家桶,其他软件也尽量从官方仓库下载安装,而非找一个野 deb/appImage/snap 包,甚至于自己编译安装。如果非要这么做,就进 docker 或者虚拟机里搞。
2022-07-31 17:42:17 +08:00
回复了 xiaoweia 创建的主题 分享发现 ThinkBook 16 + 锐龙版,是今年唯一值得入手的笔记本……
不要把 32G 版本的价格说成 16G 啊,会误导人的。
2022-07-15 18:29:54 +08:00
回复了 yodhcn 创建的主题 程序员 不限编程语言,你认为哪个 ORM 最好用?
rust 的 sqlx ,不过不是 orm 级别的库。
2022-07-11 18:26:12 +08:00
回复了 pkupyx 创建的主题 程序员 go 有没有比较合适的异常处理流程方案
@nothingistrue 你恐怕理解错我的意思了,我没有一句话说过非要自己处理错误,甚至哪怕是不应该自己处理的错误也要自己来处理。而且这和我的意思正相反,因为这不是正确的错误处理方式。

至于统一的错误处理逻辑,统一的错误处理逻辑不会导致必然的错误(但也不等于一定正确),但基本上是更方便的。很多程序员往往混淆了正确处理错误和方便处理错误两件事,因此实际的统一错误处理实践,往往就会通向方便但错误的处理模式。

当然,没有统一的错误处理逻辑,每个错误都必须显式地处理,也不等于必然的正确。就像你说的,if err != nil { print } 也是显式的处理错误方式一样。由于显式处理错误的不方便,就会让很多程序员抵触错误处理,这样也会导致错误。

但在我看来,前者与后者相比,后者起码提供了一个正确且良好的基础,只不过容易因为程序员偷懒而败坏基础。而对于前者,方便比正确更重要,这使得它的基础不够牢固。

所以个人认为,错误处理最好的实践应该是在尽可能显式处理错误的基础上,给程序员提供语法糖、胶水方法、linter 之类的工具,让错误处理变得方便。
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   969 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 20:21 · PVG 04:21 · LAX 13:21 · JFK 16:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.